From: lisar (Lisa Robinson) 

Sent: Wednesday, February 01 , 1 995 1 2:46 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'woody' 

Cc: 'geert'; 'tbr' 

Subject: test status 


BOM 216 running on IKOS 

BOM 214 ish + uu running on the zycads 

uncrupt_0 } 
uncruptharder_0 } 

brpcrupt_0 } jeffm looking at trace in 

/n/rhodan/ s3 /euterpe/verilog/bsrc/res/31195 . 19038 
brpcrupt2_0 } 
brpcrupt3_0 } 

icacheannoying 0 216 - Dump in /u/tbr/euterpe/verilog/bsrc . . . 
problem understood 

dcache_func_l 216 hung dcachenoalloc dump available 

dcache_sz_4k_l 216 went to X } Trace in 

/n/rhodan/ s3 /euterpe/verilog/bsrc/res/3 0195 .18441 
dcache_sz_8k_l 216 went to X } 

dcache_sz_16k_l 216 went to bad very early in the test } 

saaseasy 216 - went to bad dump available in 

/u/ tbr/euterpe/verilog/bsrc 
scaseasy 216 - went to bad 


exlocktest_0 


oc-interrupt_U 216 - hung - trace in 

/n/rhodan/s3 /euterpe/verilog/bsrc/res/3 1195 .21231 

brmisstest_0 

bdownharder_0 216 - X - Dump avaiable on 

/n/nosf eratu/s2/euterpe/verilog/bsrc 

bgate_U 

ltlb_l 216 - failed unexpected event - trace in 

/n/rhodan/s3/euterpe/verilog/bsrc/res/31195 . 19945 

exlltest Heck I'm trying to get a dump! (4th try) 

dram_load_conf igl_0 } 

dram_store_unique_conf igl_0 } Test build problem (.config said 0) 
dramharder_conf igl_0 } 

cerbarbeasy_0 I need to talk to Rich and Jeffm about this one 


eventdaemontest_0 214 trace available on 

/n/aphrodite/s2/euterpe/verilog/bsrc2/res/31195 .27853 

nb_slow 216 - failed - unexpected interrupt - trace 

/n/rhodan/s3/euterpe/verilog/bsrc/res/3H95 . 21016 

reg_conflict 216 - X - trace 

/n/rhodan/s3/euterpe/verilog/bsrc/res/31195 . 22026 

exrleasy 214 - dump on /n/nosf eratu/s2 ... problem 

understood 


xlu_f ield_5_l 216 running now 

Have not yet been run: 
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saastest_0 
scastest_0 

watchtest_0 

dcache _stress_l 
dcache_except_l 

nb_l 

nb_hermes_l 
nb_combo_l 

oc-synch_U 
oc_align_at 
align_ld_l 
align_st_l 

doubleextest_Q 

cerberrtest_0 

cerbstarttest_0 

doublemctest_0 

iorupttest_0 

ruptpintest_0 

brimmlongtestO 

inter rupt_l 

mem_l 

cache_l 

except ion_l 

bgate_i 

barrel_l 

synch_l 

gtlb_miss_l 

dcache_j?erf_ldlt_l 
dcache_perf_stlt_l 
dcache_perf_ldstlt_l 
dcache_perf_ldst5t_l 

addr_map_dram 

fva_conf lict_l 
herme s_c onf 1 i c t_l 
dca che_conf lie t_l 
atomic_conf lict 1 

interrupt_U 

except ion_u 

bgateJJ 

mera_U 

tlb_U 

synch_U 

barrel_U 

cache_U 

gtlb miss_U 

Cannot yet be run: 


instr__U 
instr_l 
tlb_l 
insn_l 

Newly available tests 


xlu_rotate_l__l 
xlu_rotate_2_l 
xlu_expand_l_l 
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xlu 
xlu_ 
xlu_ 
xlu_ 
xlu_ 
xlu_ 
xlu_ 
xlu_ 
xlu_ 
xlu_ 
xlu 
xlu 


compress_l_l 
extract_l_l 
f ield_l_l 
f ield_2_l 
field_3_l 
field_4_l 
copyswap_l_l 
copyswap_2_l 
copyswap_3_l 
copyswap_4_l 
shuf f lemux_l_ 
select 1 1 


Not yet implemented: 

syncharder not imp 

brcolltest_0 ; notimp 

brcrosstest_0 ; notimp 

exf ixtest_0 ? notimp 

expriotest_p ? notimp 

uuseqtest; notimp 

canceltest; notimp 

hermtotest; notimp 

cerbtotest; notimp 

hermerrtest; notimp 

cerberrtest; notimp 

eventregtest ; notimp 

exintbashtest ; notimp 

addre s s_map ; not imp 
instcache notimp 

cerb_registers_0 ; notimp 

cerberror_0 ; notimp 

testerinit_0 ; notimp 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 

Wednesday, February 01, 1995 2:42 AM 

•Bill Zuravleff 

'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert (Geert Rosseel)'; 'mws (Mark 
Semmelmeyer)'; 'tbr (Tim B. Robinson)'; 'wampler (Kurt Wampler)'; "woody (Jay Tomlinson)' 
Re: New top-level Euterpe 


Bill Zuravleff writes: 
Geert writes: 

> I am a bit worried because there seems some slow but steady growth 
>going on in the blocks : dr and ice seem to have grown the most , ... 

To be fair, dr has not grown by a single cell ( ! ) . The maximum 
width has grown, in an attempt to fix inter block timing failures 
by shortening metal lines. (BTW, for every cell I moved to the 
UpperRightHandCorner , I moved one out. I guess I didn't move 
out an atom for every one I moved in.) 

One possible solution might be to relax the #rows parameter 
over which pifpak move sticking out rows, but this may undo 
desired cell placement. 

Suggestions? 


You might try the "-eachRow" option to Pifpack. 

This will make the contour of DR "smoother" though not necessarily more uniform. 


billz 


-hopper 
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From: geert (Geert Rosseel) 

Sent: Wednesday, February 01 , 1 995 3:25 AM 

To: 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'tor'; 'wampler'; 'woody' 
Subject: New top-level Euterpe 

Hi, 

I build a new top-level Euterpe. Kurt : it is ready for routing . 

This one has the improved stripes next to the caches, plus a better 
cerberus but still has the old data-path. 

I am now running a timing pass. We should have the data by the morning, 

I am a bit worried because there seems some slow but steady growth 
going on in the blocks : dr and ice seem to have grown the most, he 
is not as symmetric as it used to be, it is larger at the bottom than 
at the top. 

nb, at, sr look really good .. I used to have to do manual work on 
these, this ti em, I didn't have to do anyhting ... 


Geert 
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From: 
Sent: 
To: 

Subject: 


billz (Bill Zuravleff) 

Wednesday, February 01, 1995 10:29 AM 

'brlanl'; 'dickson*; 'geerf; 'hopper; 'mws'; 'tbr'; 'wampler'; 'woody' 

Re: New top-level Euterpe 


Geert writes: 

> I am a bit worried because there seems some slow but steady growth 
>going on in the blocks : dr and ice seem to have grown the most, . . . 

To be fair, dr has not grown by a single cell (I) . The maximum width has grown, in an 
attempt to fix inter block timing failures by shortening metal lines. (BTW, for every 
cell I moved to the UpperRightHandCorner , I moved one out. I guess I didn't move out an 
atom for every one I moved in. ) 

One possible solution might be to relax the #rows parameter over which pifpak move 
sticking out rows, but this may undo desired cell placement. 

Suggestions? 


billz 
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From: jeffm (Jeff Marr) 

Sent: Wednesday, February 01 , 1995 1 0:53 AM 
To: 'billz (Bill Zuravleff)' 

Cc: 'dickson (Richard Dickson)'; 'jeffm (Jeff Marr)'; 'lisar (Lisa Robinson)'; 'Mark Semmelmeyer'; Tim B. 
Robinson'; 'Jay Tomlinson' 

Subject: dcachenoalloc 

Bill Zuravleff writes: 

> Y'all, 

> test dcachenoalloc goes to X's (examined in -tbr/euterpe/verilog/bsrc). 

> Because LTcdMissVldCcR12 goes high while LTcdMissR12 is X. 

> Because TDtagR7R8 is X (throughout the test). 

> 

> At this point I'll have to parse the test a bit better, but ... 

> 

> Surely a load or store noalloc working depends on the tag being 

> properly initialized (it's got to know whether it was a hit or not). 

> Does dcachenoalloc initialize the tags? 

> 

> The entire tag has unknown values at the beginning and end of the 

> test. 

> 

> Regards, 

> billz 

I had checked in a fix to the makefile to create a .ctd file. 
Did this run get done after the fix? Did the tag get loaded? 

jeffm 
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From: geert (Geert Rosseel) 

Sent: Wednesday, February 01 , 1 995 1 1 :58 AM 

To: 'billz 1 ; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'tor'; 'woody' 

Subject: Latest top-level run 


Hi, 


Here are the timing violations of the latest top-level run. 

This is quite a bit better than last time. We now have 
about 550 timing violations, 380 of which in uu. 

More detailed info is in : 

/n/gh i dra/s3/geert/euterpe/verilog/bsrc/gards/geert_euterpe-top . stat 
(look for HARD ERROR) 


******** 

nb to dr : 1 8 errors 
******** 

Warning! Cycle time exceeded by 43.33ps using cycle time of 926.00 for Iteration 1 HARD ERROR 4 
Path After Optimization using cycle time of 926.00: 

nb/nbprbarb/UgO/uO (xborffb8df32s 32S) Oport: QAD0PF IntDel: 89.50 net: NBdrprgrant_N swg: df delay: 
415.27ps (force) RC delay: 178.52ps Ids: 7 pcap: 49.32ff cap: 642.44ff (ext) m21en: 0.00 m3len: 5392.00 m4len: 
000 

dr/drout/drprbcsm/UprbSel_6_0/u0 (xbor5df32s 32S) Iport: D3_A0PF Oport: Q_AND0PF IntDel: 172.50 net: 
dr/drout/drprbcsm/prbSel_N_6_0 swg: df delay: 13.06ps (force) RC delay: 0.21 ps Ids: 2 pcap: 9.77ff cap: 29.07ff 
(ext) m2len; 32.00 m31en: 97.00 m41en: 0.00 

dr/drout/drprbcsm/UprbSel_6/u0 (xborff3dh4s 4S) Iport: D0_A0PF IntDel: 279.00 

Time through Path: 969.33 


nbtohcl : 7 errors 
******* 

Warning! Cycle time exceeded by 66.03ps using cycle time of 926.00 for Iteration 1 HARD ERROR 20 
Path After Optimization using cycle time of 926.00: 
nb/nbprbarb/Ug2/uO (xborffb6df32s 32S) Oport: Q_AND0PF IntDel: 87.80 net: NBhclprgrant_N swg: df 
delay: 41 8.53ps (force) RC delay: 161.73ps Ids: 5 pcap: 46.97ff cap: 61 l.49ff (ext) m2Ien: 0.00 m31en: 5132.00 
m41en: 000 

hcl/u420/Unst_2_2/uO (xbor8df32s 32S) Iport: D6_A0PF Oport: Q AND0PF IntDel: 183.80 net: 
hcl/u420/nst_N_2_2 swg: df delay: 22. lOps (force) RC delay: 0.61 ps Ids: 3 pcap: 1 8.8 1 ff cap: 43.01 ff (ext) 
m21en: 0.00 m31en: 97.00 m41en: 145.00 

hcl/u420/Unst_0/uO (xborffl5dfl2s 12S) Iport: D12_A0PF IntDel: 279.80 

Time through Path: 992.03 

******* 
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cc to nb : 85 errors 
******* 

Warning! Cycle time exceeded by 106.77ps using cycle time of 926.00 for Iteration 1 HARD ERROR 25 
Path After Optimization using cycle time of 926.00: 

cc/ccstart/Unbgob/uO (xborffb3df32s 32S) Oport: Q_AD0PF IntDel: 89.50 net: CCnbgobR13_N swg: df 
delay: 469.54ps (force) RC delay: 207.98ps Ids: 16 pcap: 104.88ff cap: 71 1.86ff (ext) m21en: 0.00 m31en: 5518.00 
m41en: 0.00 

nb/fqcount/Ucout_2_6/u0 (xbor4df32s 32S) Iport: D3_A0PF Oport: Q AND0PF IntDel: 184.10 net: 
nb/fqcount/cout_N_2_6 swg: df delay: 18.83ps (force) RC delay: 0.44ps Ids: 2 pcap: 14.29ff cap: 35.49ff (ext) 
m21en:0.00 m31en: 97.00 m41en: 115.00 

nb/fqcount/Ucouta_2Ai0 (xborffl3df8s 8S) Iport: D6_A0PF IntDel: 270.80 

Time through Path: 1032.77 


******** 

at to cc : 4 errors 
******** 

Warning! Cycle time exceeded by 14.38ps using cycle time of 926.00 for Iteration 1 HARD ERROR 1 09 
Path After Optimization using cycle time of 926.00: 

at/UctPaRl 1R121/U0 (xbhrdf32s 32S) Oport: QAD0PF IntDel: 245.40 net: LTctPaR12<0> swg: df delay: 
210.46ps (force) RC delay: 56.43ps Ids: 3 pcap: 26.67ff cap: 360.85ff(ext) m21en: 0.00 m31en: 3038.00 m41en: 0.00 

cc/ccstart/Ustartml_0/uO (xbor8df32s 32S) Iport: D5_A0PF Oport: Q_AND0PF IntDel: 177.70 net: 
cc/ccstart/startml_N_0 swg: df delay: 26.52ps (force) RC delay: 0.78ps Ids: 6 pcap: 33.5 Iff cap: 56.0 Iff (ext) 
m21en: 0.00 m3Ien: 9.00 m41en: 216.00 

cc/ccstart/UaSelc2/u0 (xborff5dh6s 6S) Iport: D2_A0PF IntDel: 280.30 

Time through Path: 940.38 


******** 

au to ctiod : 8 errors 
******** 

Warning! Cycle time exceeded by 29.07ps using cycle time of 926.00 for Iteration 1 HARD ERROR 1 17 
Path After Optimization using cycle time of 926.00: 

au/ul 12/uO (xbmuxffb2dh24s 24S) Oport: q_and0ph IntDel: 89.40 net: AUndxl500R2_N<6> swg: dh delay: 
612.17ps (force) RC delay: 396.65ps Ids: 5 pcap: 37.98fT cap: 945.92ff(ext) m21en: 0.00 m31en: 8254.00 m41en: 0.00 

ctiod/muxff2_8ra/u0 (xbmuxf¥2df4s 4S) Iport: D1AND0PH IntDel: 253.50 

Time through Path: 955.07 


********* 

uu to nb : 4 errors 

Warning! Cycle time exceeded by 5.08ps using cycle time of 926.00 for Iteration 1 HARD ERROR 124 
Path After Optimization using cycle time of 926.00: 

uu/Urst9CUS/uO (xbffbdh24s 24S) Oport: q_adOph IntDel: 89.40 net: UUrstUS swg: dh delay: 587.58ps (force) 
RC delay: 376.01 ps Ids: 7 pcap: 61.04ff cap: 928.83ff (ext) m21en: 0.00 m3ten: 7889.00 m41en: 0.00 

nb/ff_r0/u0 (xbffbdh8s 8S) Iport: D0_ADMPH IntDel: 254. 10 

Time through Path: 93 1.08 

******** 

uu to ice : 2 errors 
******** 

Warning! Cycle time exceeded by 6.25ps using cycle time of 926.00 for Iteration 1 HARD ERROR 127 
Path After Optimization using cycle time of 926.00: 
uu/Urst9CUS/uO (xbffbdh24s 24S) Oport: q_and0ph IntDel: 89.40 net: UUrstUS_N swg: dh delay: 588.75ps 
(force) RC delay: 376.92ps Ids: 7 pcap: 61.04ff cap: 929.93ff (ext) m21en: 0.00 m3len: 7899.00 m41en: 0.00 
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icc/UrstOUT/uO (xbffdh 1 2s 1 2S) Iport: D0_ANDMPH IntDel : 254 . 1 0 
Time through Path: 932.25 


*** ***** 

in uu : 360 errors 
******** 


******* 

uu to dr, ctiod, nb, hcO, hcl, gt : 10 errors 


Warning! Cycle time exceeded by 245.03ps using cycle time of 926.00 for Iteration 1 HARD ERROR 481 
Path After Optimization using cycle time of 926.00: 

uu/UetaOutUT/uO (xbffbdh24s 24S) Oport: q_and0ph IntDel: 89.40 net: UUetaUTRl 1_N<0> swg: dh delay: 
794.33ps (force) RC delay: 544.15ps Ids: 1 pcap: 7.52fT cap: 1 096.4 Iff (ext) m21en: 0.00 m31en: 9899.00 m4len: 0.00 

dr/ffcbl/uO (xbffdh2s2S) Iport: D0_ANDMPH IntDel: 287.30 

Time through Path: 1 1 7 1 .03 


******* 

iq to uu : 5 errors 
******** 


Warning! Cycle time exceeded by 38.22ps using cycle time of 926.00 for Iteration 1 HARD ERROR 494 
Path After Optimization using cycle time of 926.00: 

iq/UinstLQS/uO (xbmuxffb8dh24s 24S) Oport: q_and0ph IntDel: 89.40 net: IQinstQS_N<0> swg: dh delay: 
61 1.72ps (force) RC delay: 398.02ps Ids: 1 pcap: 7.70ff cap: 938.08ff(ext) m21en: 0.00 m31en: 8458.00 m41en: 0.00 

uu/Uinstl500UR/uO (xbmuxff3dfl6s 16S) Iport: D2 AND0PH IntDel: 263.10 

Time through Path: 964.22 
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From: billz (Bill Zuravleff) 

Sent: Wednesday, February 01, 1995 4:15 PM 

To: 'jeffm (Jeff Marr)'; 'lisar (Lisa Robinson)'; 'mws (Mark Semmelmeyer)'; 'Jay Tomlinson'; 'Richard 
Dickson'; Tim B. Robinson' 

Subject: dcachenoalloc_V 

Re: dcachenoalloc_V 
Y'all, 

I'm running with BOM 216.0. 
This instruction: 

000800000c00048 <branch_to_self+24> 0x92185000 164H r5,r6,0 

hiccoughs 44 times until MAXCYCLES is exceeded. 

Anybody got any ideas on why or where to probe further? 

Complete results available in ~billz/euterpe/verilog/bsrc/dcachenoalloc_V*. 

Regards, 
billz 


Some of dcachenoalloc_V.lst: 

0000800000c00020 <start+20> 0x92 18d000 164 li rl3,r6,0 

0000800000c00024 <branch_to_selP> 0xf534c000 bne rl2 } rl3,0000800000c00024 <branch_to_self> 

0000800000c00028 <branch_to_self+4> Oxdc 180008 ecopyi r6,8 

0000800000c0002c<branch_to_self+8> 0xdfl86b36 eshli r6,r6,44 

0000800000c00030 <branch_to_self+c> 0xdc2007f8 ecopyi r8,0x7f8 

0000800000c00034<branch_to_self+10> 0xdf208336 eshli r8,r8,12 

0000800000c00038<branch_to_self+14> 0xdf206192 eor r6,r8,r6 

0000800000c0003c <branch_to_self+l 8> 0xb2 1 8c000 s641i r 1 2,r6,0 

0000800000c00040 <branch_to_self+ 1 c> Oxdc 1 80002 ecopyi r6,2 

0000800000c00044<branch_to_self+20> 0xdfl86b36 eshli r6,r6,44 

0000800000c00048 <branch_to„self+24> 0x92185000 164H r5,r6,0 

0000800000c0004c<branch_to_self+28> Oxdc 180008 ecopyi r6,8 

0000800000c00050<branch_to_self+2c> 0xdfl86b36 eshli r6,r6,44 

0000800000c00054 <branch_to_self+30> 0xdc200800 ecopyi r8,0x800 

0000800000c00058<branch_to_self+34> 0xdf208336 eshli r8,r8,12 

0000800000c0005c <branch_to_self+38> 0xdf206192 eor r6,r8,r6 

0000800000c00060<branch_to_self+3c> 0x921870a0 164H r7,r6,0xa0 

0000800000c00064 <branch_to_self+40> 0xf51c502c bne r5 s r7,0000800000c001 14 <_fail> 


End 


Exhibit Cll 


Page 11 of 559 


Cc: 

Subject: 


From: 
Sent: 
To: 


Loretta Guarino [guarino@rimulac.microuriity.com] 
Wednesday, February 01, 1995 7:51 PM 

'guarino@rimulac.microunity.com'; 'sandeep@rimulac.microunity.com'; 

•gmo@rimulac.microunity.com'; , jeffm@rimulac. microunity.com'; 

'wayne@rimulac.microunity.com'; 'gregg@rimulac.microunity.com' 

'hestia@rimulac.microunity.com' 

Software Bringup Meeting Minutes - February 1, 1995 


Software Bringup Meeting 


February 1, 1995 


Next Meeting: 


February 8 at 10:00 am. 


Attendees: jeffm, guarino, gregg, gmo, sandeep 


New Action Items 


Item: IKOS support for "fake calliope" 
Who: jeffm 
Status : New 

In order to run our realtime benchmark test, we need some way 
to get data in and out of the HW simulator at the speed 
of a Calliope access. We would also like some way to cause 
fake calliope events to be posted at regular intervals. 

Item: Status of Euterpe/Mnemo simulation 
Who: jeffm, gmo 
Status: New 

gmo to investigate terp support for mnemo, jeffm to find out 
plans for hardware simulation. 

Item: Test interleaved access 
Who : guarino 
Status : New 

Create a test that exercises interleaved mnemo accesses . 
Depends on terp support for interleaving. 

Item: Create a microkernel that doesn't access calliope 
Who : sandeep 
Status : New 

Item: Build microkernel tests for IKOS 
Who: sandeep, doi 
Status : New 

Create images for boot test, snapshot images for microkernel 
tests . 

Item: DVT boot 
Who : sandeep 
Status : New 

Create simple boot for DVTs . 

Item: Unsnap code 
Who: sandeep, guarino 
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Status : New 

This is an extension to the boot code. 

Item: Real-time test 
Who : gregg 
Status: New 

Modify the mpeg benchmark to run on the HW simulator. 

Review of Action Items 


Item: Rerun dcacheharder and icacheharder tests and get cycle count 
results . 
Who: doi 

Status: [01/11] Unknown 

The dcacheharder and icache harder s tests should run now. 

Item: More investigation on CBI and workstation interface issues. 
Who: guarino, wayne 
Status: In progress 

Loretta/ Guillermo, Curtis, Tim and Lisa need to meet to 
agree on requirements and strategy. 


Item: Implement parallel port device driver for Linux on PC. 
who: jerry, doi 

Status: On hold, until we decide on cross- environment debug strategy. 


Item: Define and implement a snapshot environment for the HW and SW 

simulators . 
Who: jeffm, gmo, guarino 
Status: [11/30] In progress 

Jeff showed us first cut at his high-level thoughts. The team 
will review and supplement the proposal. 


Item: Build scripting/Ul capabilities above gdb for regression tests. 
Who : doi 

Status: On hold until the the boot, gdb boot stub, and virtual devices 

are complete. 


Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/30] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance. 

We still need to put together the actual performance tests that 
need to be run on the hardware. 


Item: Simulator needs to understand "reset 1 
Who : gmo 

Status: [11/3 0] In progress. Target finish of 1/20. 

Gmo is testing this functionality. 

Item: Implement and bring-up boot, gdb boot stub, and virtual device 
support on the software simulator. 
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Who : s ande ep / gmo 

Status: In progress. Target finish of [1/103 2/10. 

Basic /dev/host I/G and booting the microkernel is checked in. 
Sandeep anticipates finishing remote debugging by 2/3, /dev/host 
extensions by 2/10. 


Completed Items 


Item: Continue trying to find either source code for parallel drivers 

or descriptions of hardware so we can write our own. 
Who: gmo sgi machines 
Who: doi sun machines 
Status: Cancel 

We are giving up plans to connect the CBI directly to our 
workstations . 


Test Status 


Jeff talked about test and debug status. 
Software Simulator Status 


Requests for additional terp functionality: 

Reset (in test) 

X (uninitialized) values 

checkpoint / snapshot 

Hermes devices at all Hermes addresses 

Observe functionality of Cerberus bits (e.g. Hermes 

channel enable) 
Wrapping spaces (especially DRAM) 
"fake calliope" support 

holes in the address space, unimplemented Hermes channels 
to cause machine checks 
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From: tbr 

Sent: Wednesday, February 01, 1995 8:37 PM 

To: Vo (Tom Vo)' 

Subject: Re: cli 

Follow Up Flag: Follow up 
Flag Status: Red 


Tom Vo wrote (on Tue Jan 31): 

Tim B. Robinson wrote .... 

> 
> 

>Tom Vo wrote (on Tue Jan 31): 

> 

> Tim B. Robinson wrote .... 

> > 

> > 

> >Is it right that we are using the same vrr for both the vrr and vtt 

> >inputs to cli? 

> > 

> >Tim 

> > 
> 

> Does not sound right . The vtt inputs to cli should be the same as the ones 

> going to iobyte . 

> 

>Please take a look at euterpe. That's where I copied it from. 

> 

>Tim 

> 
> 

The one in euterpe. V needs fixing too . 

A similar problem exists in calliope with the cell clio 

where it propagated to euterpe. V then mnemo.V . 

This hook up error prevents us from trying all values of 
termination resistances unless the knob dedicated to clio 
is set to 1 1 1 . The values permitted is the bitwise AND 
of clio knob setting and termination value setting from 
cerberus . 

I've issued a gnat report on this problem for calliope and 
checked in a change for euterpe . 

Thanks. Please fix mnemo.V too . . . 

Tim 
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To: 

Subject: 


Sent: 


From: 


tbr 

Wednesday, February 01, 1995 9:39 PM 
'dickson (Richard Dickson)' 
euterpe/verilog/bsrc/nb nb.V nbjop.pim 


Follow Up Flag: Follow up 
Flag Status: Red 

Richard Dickson wrote (on Wed Feb 1): 

Update of /p/cvsroot/euterpe/verilog/bsrc/nb 

In directory ghidra:/N/rama/root/s5/dickson/euterpe/verilog/bsrc/nb 

Modified Files: 

nb.V nb_top.pim 
Log Message: 
eta fannout 

Did you get to the bottom of it - ie had an earlier edit got lost? 


Tim 
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To: 


Subject: 


From: 


Sent: 


tbr 

Wednesday, February 01, 1995 10:11 PM 
'lisar' 

forwarded message from Tim B. Robinson 


Follow Up Flag: Follow up 
Flag Status: Red 

I'm sure I didn't send this to myself! What's going on? 

Start of forwarded message 

Return-Path: <tbr@godzilla> 

Received: from godzilla.microunity.com by gaea.microunity.com (4.1 /muse 1.3) 

id AA02612; Wed, 1 Feb 95 16:16:08 PST 
Received: from localhost by godzilla.microunity.com (8.6.4/muse-sw.2) 

id QAA27220; Wed, 1 Feb 1995 16:16:07 -0800 
Message-Id: < 1 995020200 1 6.QAA27220@godzilla.microunity.com> 
From: tbr@godzilla (Tim B. Robinson) 
To: tbr@godzilla 
Subject: getbom 

Date: Wed, 1 Feb 1995 16:16:07 -0800 
I did a getbom and got. 

/n/auspex/sl5/tbr/euterpe/verilog/bsrc: File "euterpe.V" has local modifications - moving to .#euterpe.V.6.355 - (status 4) 
/n/auspex/sl5/tbr/euterpe/verilog/bsrc: File "euterpe_wrap.V" has local modifications - moving to .#euterpe_wrap.V.l 5.79 - 
(status 4) 

tbr@godzilla ~/euterpe/verilog/bsrc 405 % diff euterpe.V .#euterpe.V.6.355 
lcl 

< // $Id: euterpe.V, v 6.356 1995/01/30 19:42:23 LT mws Exp $ 

> // Sid: euterpe.V,v 6.355 1995/01/30 19:07:55 LT tbr Exp $ 
671c671 

< tclk_abdlph, // buffrd 54MHz 

> tclk_abdlph, // buffered 54MHz 


> ,D(RGplRl) ,D(RGiSqntlNwSegR2) 

> ,D(RGplR2) ,D(RGiSqntlNwSegR3) 
1813at816 

> ,D(RGiSqntlNwSegR2) 
1821cl824 

< ,DB(ETrsltWM, 63 :2)/*PL is staged in rgpc from rsltR9*/ 

> ,DB(ETrsltWM,63:0) 


End of forwarded message — 


1550al551 

> wire 
1702al704 

> wire 


D(RGiSqntlNwSegR3) ; // >» dead? 


D(RGiSqntlNwSegR2); //»>dead? 


1740,1741cl742,1743 

< ,D(RGplRl) 

< ,D(RGplR2) 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Wednesday, February 01, 1995 10:48 PM 

'geert (Geert Rosseel)'; 'torn (Thomas Laidig)'; 'hopper (Mark Hofmann)' 

Vanthof (Dave Van't Hot)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'vo (Tom Vo)' 

contact pedestal max width rule revisted 


It's time to revisit the maximum width rule for contact pedestal. At one point when max 
width rules were thought to have gone away, contact pedestal was filled in for the pwrbase 
and crack (seal?) ring cells. We now flag these as errors. I can attempt to cut holes 
back into these (1 micron minimum), but I don't know the importance of the contact 
pedestal width in the pwrbase cells. 

There are also metal 1 min width violations in some hemming cells in the clock spars. 
There are other errors as well and if they can be fixed, I'll attempt to do so. 

In case others are interested, the error file is: 

/u/ vanthof /compass /mobi/euterpe/tapeout/euterpe_lower . err 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
inc . 

255 Caspian Way, Sunnyvale, CA (4 08) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for himi 


Thanks , 
Dave 
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From: hopper (Mark Hofmann) 

Sent: Thursday, February 02, 1 995 12:26 AM 

To: 'vant' 

Cc: 'geert (Geert Rosseel)'; Vanthof (Dave Van't Hof)'; Vo (Tom Vo)'; 'tbr (Tim B. Robinson)'; 'lisar 

(Lisa Robinson)'; 'torn (Thomas Laidig)'; 'fwo (Fred Obermeier)* 
Subject: Re: euterpep (space transformer) drc's finished 


vant writes: 

The space transformer drc's finished (snapshot version) and there are 
about 100 errors across 3 classes of errors: 

Max Metal Si feature space = 60 udrs; 

Max Metal S2 feature size (short direction) = 4 0 udrs; 
Max Metal £2 feature space = 6 0 udrs ; 

I have not looked at them yet, the error file is located: 

/u /vanthof /compass /mobi/euterpe/tapeout /euterpep . err 

By the way, the drc's only took 3 hours to run... 

Thanks , 
Dave 

Thanks Dave. 

I think this space transformer was generated awhile ago? 
Geert, do we know if it's uptodate with the baseplate? 
Maybe we should regenerate first? 

-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Thursday, February 02, 1995 12:30 AM 

Vant' 

1 hopper@MicroUnity.com'; Vanthof@MicroUnity.com'; 'geert (Geert Rosseel)'; 'vo (Tom Vo)'; 
'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'fwo (Fred Obermeier)' 
Re: euterpep (space transformer) drc's finished 


vant writes : 


Actually, this was 

generated on the 27th of January this year, so it's as upto 

date as it can be. I'm still working on the bazillions of random top level 
drc errors in the cr block but will try to get to the space transformer later 
this morning (or if someone else gets to it first, that fine too ) 


Oh, Okay, thanks Dave. I was under the impression it was an old design. . . 


Thanks , 
Dave 


thanks , 
-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Thursday, February 02, 1995 1:21 AM 
'geert (Geert Rosseel)' 

Vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'vo (Tom Vo)'; 'tbr (Tim B. Robinson)'; 
'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'two (Fred Obermeier)' 
euterpep (space transformer) drc's finished 


The space transformer drc's finished (snapshot version) and there are about 100 errors 
across 3 classes of errors: 

Max Metal SI feature space = 6 0 udrs; 

Max Metal S2 feature size (short direction) = 40 udrs; 
Max Metal S2 feature space = 6 0 udrs; 

I have not looked at them yet, the error file is located: 

/u/vanthof /compass/mobi/euterpe/tapeout/ euterpep . err 

By the way, the drc's only took 3 hours to run... 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Thursday, February 02, 1995 8:32 AM 
'Mark Hofmann' 

'vanthof@tomato.microunity.com'; 'geert (Geert Rosseel)'; Vo (Tom Vo)'; 'tbr (Tim B. 
Robinson)'; 'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'fwo (Fred Obermeier)' 
Re: euterpep (space transformer) drc's finished 


Mark Hofmann writes : 
> 

> Thanks Dave. 

>I think this space transformer was generated awhile ago? 
>Geert, do we know if it's uptodate with the baseplate? 
>Maybe we should regenerate first? 
> 

>- hopper 


Actually, this was generated on the 27th of January this year, so it's as upto date as it 
can be. I'm still working on the bazillions of random top level drc errors in the cr 
block but will try to get to the space transformer later this morning (or if someone else 
gets to it first, that fine too :-) ) 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale/ CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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From: vanthof (vant) 

Sent: Thursday, February 02, 1995 8:36 AM 

To: 'Mark Hofmann' 

Cc: Vanthof (Dave Van't Hof)'; 'geert (Geert Rosseel)'; 'two (Fred Obermeier)'; 'tbr (Tim B. 

Robinson)'; lisar (Lisa Robinson)'; Vo (Tom Vo)'; 'torn (Thomas Laidig)' 
Subject: Re: euterpep (space transformer) drc's finished 


Mark Hofmann writes : 

> 

>Oh, Okay, thanks Dave. I was under the impression it was an old design... 
> 

> thanks , 
> -hopper 


The version in /u/chip is very old, but I'm working out of the snapshot region. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 # include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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From: lisar (Lisa Robinson) 

Sent: Thursday, February 02, 1 995 9: 1 7 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Cc: 'geert' 

Subject: Test status 


BOM 218 running on Zycad 
Building BOM 220 for IKOS 

New business 


dcacheannoying_0 218 Goes to X dump on rhodan /s3 
exlltest 218 - Dump on nosferatu /s2 

oc - inter rupt_U 218 - trace in 

/n/rhodan/s3/euterpe/verilog/bsrc/res/l295 . 11572 
barrel_l 218 - trace in 

/n/rhodan/s3/euterpe/verilog/bsrc/res/l295 . 11572 
event daemontest_0 218 - trace available on 
/n/aphrodite/s2/euterpe/verilog/bsrc/res/1295 . 10568 


uncrupt_0 } 
unc rupt har der_0 } 

brpcrupt_0 } jeffm looking at trace in 

/n/rhodan/s3/euterpe/verilog/bsrc/res/31195 .19038 
brpcrupt2_0 } 
brpcrupt3_0 } 

icacheannoying_0 216 - Dump in /u/tbr/euterpe/verilog/bsrc . . . Fix 
released 

bdownharder_0 216 - X - Fix released 

dcache_func_l 216 hung dcachenoalloc dump available -tbr 

dcache_sz_4k_l 216 went to X } Traces 

in /n/rhodan/s3/euterpe/verilog/bsrc/res/30195 . 18441 
dcache_sz_8k_l 216 went to X 

dcache_sz_16k_l 216 went to bad very early in the test dump 

available for 218 but different nosferatu /s2 

saaseasy 218 - looks to be hung Lisar to get trace 

scaseasy 218 

exlocktest_0 

brmisstest_0 
bgate_U 

dram_load_conf igl_0 } 
dram_store_unique_con 
dramharder_conf igl_0 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 


dram_store_unique_conf igl_0 } Test build problem (.config said 0) 


nb_slow 216 - Fix in test 

ltlb_l 216 - Fix in test 

reg_conflict 216 - Cute software "bug" 

exrleasy 214 - dump on /n/nosf eratu/s2 . . , problem 
understood 

xlu_field_5_l 216 - X - trace 
/n/rhodan/s3/euterpe/verilog/bsrc/res/3 1195 .22454 
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Have not yet been run: 


saastest_0 
scastest_0 

watchtest_0 

dcache_stress_l 
dc a che_exc ep t _1 

nb_l 

nb_hermes_l 
nb_combo_l 

oc-synch_U 
oc_align_at 
align_ld_l 
align_st_l 

doubleextest_0 

cerberrtest_0 

cerbstarttest_0 

doublemctest__0 

iorupttest_0 

ruptp int e s t_0 

brimmlongtest_0 

interrupt_l 
raem_l 
cache 1 
except ion_l 
bgate_l 
barrel_l 
synch_l 
gtlb_raiss_l 

dcache_perf_ldlt_l 
dcache_perf_stlt_l 
dcache_j>erf_ldstlt_l 
dcache_perf_ldst5t_l 

addr_raap_dram 

fva_conf lict_l 
herme s_conf 1 i c t_l 
dcache_conf lict_l 
atomic_conflict_l 

interrupt_U 

except ion_U 

bgate_U 

mem_U 

tlb_U 

synch_U 

barrel_U 

cache_U 

gtlb_miss_U 

Cannot yet be run: 


instr_U 

instr_l 

tlb_l 

insn_l 

nulltest 

unix 

Newly available tests 
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xlu_rotate_l_l 
xlu_rotate_2_l 
x lu_expand_l_l 
xlu_compress_l_l 
xlu_extract_l_l 
xlu_f ield_l 1 
xlu_field_2_l 
xlu_f ield_3_l 
xlu_f ield_4_l 
x 1 u_c opy s wap_l_l 
x 1 u_c opy s wap_2_l 
x 1 u_c opy swap_3 _1 
x 1 u_c opy s wap_4 1 
x 1 u_shuf f 1 emux_l_l 
xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

expriotest_0 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

cerberrtest_0 

eventregtest_0 

exintbashtest_0 

cerb_regi ster s_0 

cerberror_0 

testerinit_0 

memmap_0 

doubleextest_0 

cerberrtest_0 

cerbstarttest_0 

doublemctest_0 

iorupttest_0 

ruptpintest_0 

iorupttest_0 

nbbashtest_0 

cerbraw_0 

cerbarbtests 

hcplltests 
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From: geert (Geert Rosseel) 

Sent: Thursday, February 02, 1995 1 1:56 AM 

To: 'hopper@MicroUnity.com'; Vanthof 

Cc: 'two'; 'lisar'; 'for*; 'torn'; 'vo' 

Subject: Re: euterpep (space transformer) drc's finished 

Fred should probably look at the drc errors . The space-tranmsformer 
is completely automatically generated, so most the errors are 
most likely from some corner case that was not expected ... 

Geert 
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Sent: 


From: 


tbr 

Thursday, February 02, 1995 2:02 PM 


To: 


Subject: 


Cc: 


'brianl'; 'bpw' 
'vanthof ; "age" 
Timing model 


Follow Up Flag: Follow up 
Flag Status: Red 

We will need an accurate timing model for topt for iobytem, the 
version of iobyte in mnemosyne. Unlike the euterpe version, this one 
is designed to be clocked with the same clock as the regular sofa and 
we'll want topt to be able to do a good job on the main interfaces. 
Can you get this data together please? 


Tim 
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From: tbr 

Sent: Thursday, February 02, 1995 2:04 PM 

To: 'lisar' 
Subject: euterpe. status 

Follow Up Flag: Follow up 
Flag Status: Red 


Have you taken a look at the latest version (24.22). Mark has 
consolidated all his postit notes into this. 

Tim 
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From: 
Sent: 
To: 

Subject: 


Tom Eich [tbe@MicroUnity.com] 

Thursday, February 02, 1995 2:43 PM 

'pandora@MicroUnity.com' 

DECISION IMMINENT: Fanless Euterpe Module 


DECISION IMMINENT FOR PANDORA EUTERPE MODULE TO BE COOLED BY SYSTEM LEVEL FAN. 

A fanless design for the Euterpe Module to be used in Pandora is being considered. A 
specified airflow rate will be required for adequate cooling of Euterpe or Cronos, along 
with the SDRAMS , in this module. In Pandora, this airflow will be supplied by a system 
level blower (s), as is the case for the Mnemo and Calliope modules. This approach allows 
for the simplest power distribution design, and potentially allows the most optimal system 
design for size, noise and power. 

In other applications that may use these Euterpe or Cronos modules, an appropriately sized 
fan will need to be provided along with the necessary power supply/distribution, extenal 
housing and shielding, etc. 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 089 
(408)734-8100, (408)734-8136 fax 


tbe@microunity . com 
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From: wayne (Wayne Freitas) 

Sent: Thursday, February 02, 1 995 3: 1 0 PM 

To: 'hestia' 

Subject: Voltage plane basic tests. 

Below are the initial static test being performed to measure the 
voltage drop across the main board. I have included this to a wider 

audience for those interested in knowing a little more than what is provided in the HW 
System Bring-up meetings. Currently were trying to isolate multiple shorts between the 
ground planes. Please also note that these tests have additional data involving set-up, 
and previous test data that reside in the logbook, if your interested in obtaining more 
data let me know and I'll show you how to use the logbook. 

Wayne 

Note, this is a long file. 


TEST: 


Continuation of basic power test. I'm going do a simple check of the PWB under static 
load conditions to see the voltage drop and temperature gradient across the board. Test 
conditions are as follows, Using a HP6651A linear power supply connected to the 3.3 volt 
input (where the DC-DC Module mounts) I will provide a constant voltage of 3.300VDC. Then 
using the HP6 06 0B electronic load I will vary the load in 5amp increments upto 4 5amps. At 
each increment I will measure the temperature and voltage drop at specified points. This 
test will have the 6060B configured with transients "off", and have the external sense 
line "on" connected at the power input source. 

Room temp = ~23 Degree +/-1, using a Fluke87 with 80T-IR probe. 
Load is currently only connected at Euterpe, as follows: 

using 3 sides with -35 VCC via's 8ea. 28awg wire are brought up -.1" and then connected 
to a 12awg wire that run the perimeter of the Euterpe footprint. This is then connected 
by < 6" of 12awg wire to the load. 

All voltage measurements are done using a Fluke87. Three points are measured at 
Calliope, Euterpe, and ~ 1" away form the Power Input. 


Volts Amps Points 

Eu Ca 

Po 


3 

3 0V 

1A 

0 

001, 

3 

299, 

23 

0 

001, 

3 

300, 

23 

0 

000, 

3 

300, 

23 

3 

3 0V 

5A 

0 

005, 

3 

292, 

23 

0 

003, 

3 

300, 

23 

0 

000, 

3 

300, 

23 

3 

3 0V 

10A 

0 

010, 

3 

283, 

23 

0 

007, 

3 

298, 

23 

0 

002, 

3 

299, 

23 

3 

30V 

15A 

0 

015, 

3 

274, 

26 

0 

011, 

3 

297, 

24 

0 

002, 

3 

298, 

26 

3 

30V 

2 OA 

0 

020, 

3 

265, 

27 

0 

014, 

3 

296, 

25 

0 

003, 

3 

297, 

27 

3 

30V 

25A 

0 

025, 

3 

256, 

27 

0 

018, 

3 

295, 

25 

0 

004, 

3 

295, 

29 

3 

30V 

3 OA 

0 

031, 

3 

248, 

29 

0 

022, 

3 

294, 

25 

0 

006, 

3 

294, 

31 

3 

30V 

3 5A 

0 

036, 

3 

239, 

31 

0 

025, 

3 

292, 

25 

0 

006, 

2 

293, 

33 


3.30V 4 OA 
3.30V 45A 


SUMMARY: 

Seems the temperature gradient problem I had before was due to the shorted -sense trace 
dissipating into the polyamide . Voltage drop number seem alright considering all current 
is going through the Euterpe pins and only -60% of VCC pins are connected. Will follow 
through after I add the same modification to Calliope pins. Tests will also expand to 
include additional test measurement points by the RF section. Numbers to be passed on to 
board layout engineers for verification. 

2.1.2 voltages 
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Who : wayne 

Date: Fri Jan 27 14:16:55 PST 1995 
TESTS : 

Continuation of power distribution tests. The DC-DC module is now mounted on with the 
sense wire fix and a fan running to keep it cool. Currently I have the sense resistors 
loaded for Calliope I also found out that I needed to hardwire the VCC to the 
+sense because the lead actually connects to the VCC Output 
from Calliope. 

Measurements will now be performed with a HP3 457A Multimeter 
using a 4 wire measurement. 1st I'll duplicate my previous 
set-up and measurements to establish a correlation. I'm not going 
to do any temperature measurements because of the fan, and the 
measurement device doesn't seem to like the DC-DC Modules heat 
sink. 

With the main board power off I did a simple sanity check, 
I've included them as "OA". 

Amps Points 

Eu Ca 

Po 


OA 


0 . OOmV 



0 . 0 OmV 



0 

1A 


1.18mV, 

3 .810 


0.90mV, 3.810 


0 . 000, 

3 .813 

5A 


4 . 96mV, 

3 .336 


3.27mV, 3.343 


0 . 000, 

3.344 

10A 


9.7 3mV, 

3 .333 


6.32mV, 3.353 


0.000, 

3 .355 

15A 

14 

.52mV, 3 

.341 


9.37mV, 3.363 


0.000, 3 

.367 

2 OA 

19 

. 3 3mV, 3 

.344 

12 

. 42mV, 3,373 

0 

.000, 3. 

378 

25A 

24 

. 13mV, 3 

.346 

15 

,48mV, 3.383 

0 

.000, 3. 

389 

3 OA 

28 

. 96mV, 3 

.349 

18 

.54mV, 3.393 

0 

.000, 3. 

400 

35A 

33 

. 82mV, 3 

.353 

21 

.65mV, 3.403 

0 

.000, 3. 

411 


I talked to Noel and got the following values for the chips. 
Nominal values given Calliope 17A @3 . 3V 
Euterpe 28A @3 . 3V 

Same set-up as before except Calliope now has a power ring 
and I will be using a second load for simulating various 
loading conditions. Measurements are given ~ l-2minutes 
to stabilize. 


Eu 

Ca 






Eu 







PO 














2 OA 

10A 

26 

15mV, 

3 

. 351 

23 

OOmV, 

3 

353 

0 

OmV, 

3 

.393 

25A 

10A 

30 

19mV, 

3 

.361 

25 

77mV, 

3 

379 

0 

OmV, 

3 

.405 

3 OA 

10A 

35 

91mV, 

3 

.367 

28 

92mV, 

3 

373 

0 

OmV, 

3 

.414 

3 5A 

10A 

40 

85mV, 

3 

.364 

32 

27mV, 

3 

395 

0 

OmV, 

3 

.420 

2 OA 

15A 

29 

15mV, 

3 

.360 

27 

66mV, 

3 

365 

0 

OmV, 

3 

999 

25A 

15A 

34 

04mV, 

3 

.367 

31 

03mV, 

3 

377 

0 

OmV, 

3 

411 

3 OA 

15A 

38 

96mV, 

3 

.365 

34 

lOmV, 

3 

383 

0 

OmV, 

3 

415 

35A 

15A 

44 

02mV, 

3 

.360 

37 

61mV, 

3 

390 

0 

OmV, 

3 

.433 

2 OA 

2 OA 

32 

33mV, 

3 

.369 

32 

89mV, 

3 

361 

0 

OmV, 

3 

.407 

25A 

2 OA 

37 

25mV, 

3 

.367 

3 6.15mV, 

3 

367 

0 

OmV, 

3 

.412 

3 OA 

20A 

42 

24mv, 

3 

.364 

39 

75mV, 

3 

388 

0 

OmV, 

3 

.428 

35A 

2 OA 

47 

42mV, 

3 

.362 

42 

94mV, 

3 

378 

0 

OmV, 

3 

.435 

2 OA 

25A 

35 

65mV, 

3 

.369 

38 

16mV, 

3 

353 

0 

OmV, 

3 

.407 

2 5A 

25A 

40 

61mV, 

3 

.364 

41 

45mV, 

3 

363 

0 

OmV, 

3 

.422 

3 OA 

25A 

45 

72mV, 

3 

.363 

44 

9 OmV, 

3 

373 

0 

OmV, 

3 

424 

35A 

25A 

50 

93mV, 

3 

.366 

48 

48mV, 

3 

383 

0 

OmV, 

3 

434 


Ca 


Above numbers confirm that the analog plane are pulling more 
current through them then thought. Arya and Yves have found 
multiple shorts between the analog ground and digital ground planes. 
This problem is due to the problems encountered with the way 
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we use PCAD (need input from someone to provide details) . 


Below are the numbers acquired after the lOea. via holes were 
drilled out per PR1950. The values still show some kind of short 
between the analog plane and the digital, but the amount of 
current has gone down. 


Amps 





Points 









Bu 



Ca 




Po 



OA 

0 

OOmV 




0 

OOmV 





1A 

1 

4lmV, 

3 

807 

0 

69mV, 

3 

810 

0 

. 000 , 

3 

810 

5A 

6 

43mV, 

3 

338 

2 

OOmV, 

3 

343 

0 

.000, 

3 

348 

10A 

12 

72mV, 

3 

341 

3 

7 5mV, 

3 

.353 

0 

.000, 

3 

361 

15A 

19 

OlmV, 

3 

344 

5 

5 0mV, 

3 

370 

0 

.000, 

3 

374 

2 OA 

25 

34mV, 

3 

347 

7 

25mV, 

3 

382 

0 

. 000, 

3 

387 

25A 

31 

66mV, 

3 

350 

9 

OlmV, 

3 

393 

0 

. 000, 

3 

400 

3 OA 

38 

0 6mV, 

3 

352 

10 

80mV, 

3 

405 

0 

. 000 , 

3 

412 

3 5A 

44 

52mV, 

3 

355 

12 

56mV, 

3 

416 

0 

.000, 

3 

425 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wayne (Wayne Freitas) 

Thursday, February 02, 1995 3:27 PM 

'bill'; 'for*; 'noel' 

'hestia' 

Main board power-up 


I began to look into the voltages levels during the power -up /down of the main board with 
the DC-DC Module, and saw a pretty nasty overshoot on the 3.3V. It looks like I'm going 
to have to get into this a little farther, so I'm going to need some more data. To start 
I need to know where would I get some information on what Euterpe and Calliope look like 
upon power- up/down (lump circuit) . I would also like to know if there a time requirement 
for the different power planes to track during the power-up/down process (ie what happens 
if +5v stays up 200ms after 3.3v drops)? One more thing, can someone provide me with the 
absolute maximum values (or a swag) on Calliope and Euterpe. 


Wayne 
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From: lisar (Lisa Robinson) 

Sent: Thursday, February 02, 1995 3:46 PM 

To: 'sysadm' 

Subject: godzilla 

Can't see nosferatu (nfs). 
Lisa R. 

cd /n/nosferatu/s2/euterpe 
/n/nosferatu/s2/euterpe: No such file or directory. 
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From: ken (Ken Hsieh) 

Sent: Thursday, February 02, 1995 3:59 PM 

To: 'lisar' 

Cc: 'sysadm' 

Subject: Re: godzilla 

The rpc.mountd died. 

I restarted on nosferatu. Try now. 

Ken 

> From lisar Thu Feb 2 13:45:37 1995 

> Date: Thu, 2 Feb 1995 13:45:31 -0800 

> From: lisar (Lisa Robinson) 

> To: sysadm 

> Subject: godzilla 

> Content-Length: 119 
> 

> 

> Can't see nosferatu (nfs). 

> 

> Lisa R. 

> 
> 

> cd /n/nosferatu/s2/euterpe 

> /n/nosferatu/s2/euterpe: No such file or directory. 

> 
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From: lisar (Lisa Robinson) 

Sent: Thursday, February 02, 1995 4:12 PM 

To: 'ken (Ken Hsieh)' 

Cc: 'sysadm' 

Subject: Re: godzilla 

Ken Hsieh wrote (on Thu Feb 2): 

The rpc.mountd died. 

I restarted on nosferatu. Try now. 

Ken 

Fixed thanks 
Lisa R. 

> From lisar Thu Feb 2 13:45:37 1995 

> Date: Thu, 2 Feb 1995 13:45:31 -0800 

> From: lisar (Lisa Robinson) 

> To: sysadm 

> Subject: godzilla 

> Content-Length: 1 19 
> 

> 

> Can't see nosferatu (nfs). 

> 

> Lisa R. 

> 
> 

> cd /n/nosferatu/s2/euterpe 

> /n/nosferatu/s2/euterpe: No such file or directory. 
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From: Jisar (Lisa Robinson) 

Sent: Thursday, February 02, 1 995 5:04 PM 

To: 'woody'; 'torn'; 'vant'; 'tbr'; 'geert' 

Subject: vdde 


Oh where ! Oh where ! has my vdde gone 

Oh where ! Oh where ! can it be 

Oh where! Oh where! has my vdde gone 

(and does it really matter say's she ....) 

The top level euterpe has a pin vdde 

module euterpe ( 

vdde, // for consistency with padlist file 

but I can't find it in the spivs netlist 

. subckt top tclk_abdlph kl_abm_0 kl_abm_l kl_abm_2 kl_abm 3 

clkoutl_abnd0p700v doutl_abd0p700v_0 doutl_abd0p7 00v_l 
+ doutl_abd0p700v_2 doutl_abd0p7 0 0v_3 doutl_abd0p7 0 0v_4 
+ doutl abd0p700v_5 

dout I_abd0p7 0 0v_6 dout I_abd0p7 0 0 v_7 

+ clkout0_abnd0p7 00v dout0_abd0p7 00v_0 dout 0_abd0p7 00v_l 
dout0_abd0p700v_2 dout0_abd0p700v_3 dout0_abd0p7 0 0v_4 
+ dout0_abd0p700v_5 doutO_abdOp7 0 0v_6 dout0_abd0p7 00v_7 
+ clk54m_abnd0p70 0v 

kh_abm_0 kh_abm_l kh_abm_2 kh_abm_3 clkinl_abd0p70 0v 

+ clkin0_abd0p700v fladdr_abm _0 fladdr_abm_l fladdr_abm_2 fladdr_abm_3 
fladdr_abm_4 fladdr_abm_S fladdr_abm_6 fladdr_abm_7 

+ fladdr_abm_8 fladdr_abm_9 f laddr_abm_10 f laddr_abm_ll f laddr_abm_12 
f laddr_abra_13 f laddr_abm_14 f laddr_abm_15 f laddr_abm_16 

+ f laddr_abm_17 f laddr_abm__l 8 f laddr_abm_19 dl_abm_0 dl_abm_l dl_abm_2 
dl_abm__3 dl_abm_4 dl_abm_5 dl_abm_6 dl_abm_7 

+ fldata_abm_0 fldata_abm_l fldata abm_2 fldata_abm 3 fldata_abm_4 

f ldata_abra_5 fldata_abm_6 f ldata_abm_7 vddts sd_bm xres_v 

+ sc_am dh_abm_0 dh_abm_l dh_abm_2 dh_abm_3 dh_abm__4 xvdda_v 

+ f 1 c hpen_abnm 

dinl_abnd0p7 0 0v_0 dinl_abnd0p7 0 0v_l 

+ dinl_abnd0p7 00v_2 dinl_abnd0p700v_3 dinl_abnd0p7 0 0v_4 
+ dinlabnd0p7 00v_5 

dinl_abnd0p7 00v_6 dinl_abnd0p7 0 0v_7 

+ dinO_abndOp7 0 0v_0 din0_abnd0p7 00v_l din0_abnd0p7 00v_2 
+ din0_abnd0p7 0 0v_3 

dinO_abnd0p7 0 0v_4 din0_abnd0p700v_5 

+ din0_abnd0p7 0 0v_6 din0_abnd0p7 0 0v_7 clkoutl_abd0p700v 
+ clkout0_abd0p7 0 0v 

clk54m_abd0p7 00v flchrdy_abm f lchirq_abm vddepl 

+ vddepO doutl_abnd0p700v_0 doutl_abnd0p7 00v_l doutl_abnd0p7 00v_2 
doutl_abnd0p7 0 0v_3 doutl_abnd0p70 0v_4 doutl_abnd0p7 0 0v_5 
+ doutl_abnd0p7 0 0v_6 doutl_abnd0p70 0v_7 dout0_abnd0p700v_0 
dout0_abnd0p7 0 0v_l dout0_abnd0p7 0 0v_2 dout0_abnd0p7 0 0v_3 
+ doutO_abndOp7 0 0v_4 doutO_abndOp700v_5 dout0_abnd0p7 00v_6 
doutO_abndOp7 00v_7 dinl_abd0p700v_0 dinl_abd0p7 0 0v_l 

+ dinl_abd0p7 0 0 v_2 dinl_abd0p700v_3 dinl_abd0p7 0 0v_4 dinl_abd0p70 0v_5 
dinl_abd0p7 0 0v_6 dinl_abd0p7 00v_7 flwrten_abnm 

+ clkinl_abnd0p70 0v clkin0_abnd0p700v dinO_abdOp7 0 0v_0 dinO_abdOp700v_l 
dinO_abdOp7 00v_2 din0_abd0p7 00v_3 din0_abd0p7 0 0 v_4 

+ dinO_abdOp700v_5 din0_abd0p700v_6 din0_abd0p7 0 0 v_7 sdclock3_abm 
sdclock2_abm sdclockl_abm sdclockO_abm flouten_abnm 

+ sdd_abm 0 sdd_abm_l sdd_abm_2 sdd_abm_3 sdd_abm_4 sdd_abm_5 sdd_abm_6 
sdd_abm_7 sdd_abm_8 sdd_abm_9 sdd_abm_lO sdd_abm_ll 

+ sdd abm 12 sdd abm 13 sdd abm__14 sdd_abm_15 sdd abm_16 sdd_abm_17 
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sdd_abm_JL8 sdd_abm_19 sdd_abm_20 sdd_abm_21 sdd_abm_22 

+ sdd_abm_23 sdd_abra_24 sdd_abm_25 sdd_abra_2 6 sdd_abm_27 sdd_abm_2 8 

sdd_abm_2 9 sdd_abm_3 0 sdd_abm_31 sn_abin_0 sn_abm_l 

+ sn_abm_2 sn_abm_3 sdc_abm_0 sdc_abm_l sdc_abm_2 sdc_abm_3 sdc_abm_4 

scout_am sda_abm_0 sda_abm_l sda_abm_2 sda_abm_3 

+ sda_abm_4 sda_abm_5 sda_abm_6 sda_abm_7 sda_abm_8 sda_abm_9 

+ sda_abra_10 

sda_abm_ll sda_abm_12 mltdinhib_abm dinvrr2 abm 

+ tpout_v dinvrrl_abm dinvrrO_abm vref_Oph vref6_0ph vrr6_0 vrr6_l 
+ vrr6_2 

phi_b2p phi a2p vii6 


Lisa R. 
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From: lisar (Lisa Robinson) 
Sent: Thursday, February 02, 1995 6:08 PM 
To: 'mws'; 'woody'; 'dickson'; 'billz'; 'jeffm'; 'tbr' 
Subject: Update: Test Status 


Just an update, page me if you need more dummping 

BOM 218 running on Zycad 
BOM 220 running on IKOS 


New business 


dcacheannoying_0 2 1 8 - Goes to X dump on rhodan /s3 

ex 1 1 test 2 1 8 - Dump on nosferatu /s2 

uncruptharder_0 220 - Dump on nosferatu /s2 

dcache_func__l 216 - hung dcachenoalloc NEW dump available ~tbr 

dcache_sz_l 6k_l 2 1 6 - went to bad very early in the test dump available for 2 1 8 but different nosferatu /s2 


barrel 1 


218 - trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/l 295.1 1572, recreating with smaller test dramex 


scaseasy 


218 - Dump on nosferatu /s2 - Problem understood 
218 


uncrupt_0 
brpcrupt_0 
brpcrupt2_0 

icacheannoyingj) 
bdownharder 0 


} 

} Lisar to re-run for longer 
} 

216 - Dump in /u/tbr/euterpe/verilog/bsrc ... Fix released 
216- X - Fix released 


Old Business 


dcache_sz_4k_ 1 2 1 6 - went to X } Traces in /n/rhodan/s3/euterpe/verilog/bsrc/res/30 1 95 . 1 844 1 
dcache_sz_8k_l 2 1 6 - went to X 

exlocktest_0 

brmisstest 0 
bgate_U 

dram_load_configl_0 } 

dram_store_unique_configl_0 } Test build problem (xonfig said 0) 
dramharder_con fig 1 0 } 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 


nb_slow 2 1 6 - Fix in test 

ltlb_l 216 -Fix in test 

reg_conflict 216 - Cute software "bug" 

exr 1 easy 2 14 - dump on /n/nosferatu/s2 ... problem understood 

xlu_field_5_l 2 1 6 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/3 1 1 95 .22454 


Exhibit Cll 


Page 40 of 559 


Have not yet been run: 


saastestO 
scastest_0 

watchtest_0 

dcache_stress_l 
dcache_except_l 

nb_l 

nb hercnes 1 
nbcombol 

oc-synch_U 
oc_align_at 
align Id 1 
alignstl 

doubleextest_0 

cerbentest_0 

cerbstarttest_0 

doublemctest_0 

iorupttestO 

ruptpintest_0 

brimmlongtest_0 

interruptl 

meml 

each el 

exception_l 

bgatel 

barrell 

synch_l 

gtlb_miss_l 

dcache__perf_ldlt_l 
dcache_perf_st 1 t_l 
dcache_perf_ldstlt_l 
dcachejDerf_ldst5t_l 

addr_map_dram 

fvaconflictl 
hermes_conflict_l 
dcache_conflict_l 
atomic_conflict_l 

interrupt_U 

exceptionJJ 

bgate_U 

mem U 

tlb„U 

synch_U 

barrel__U 

cache_U 

gtlb_miss_U 

Cannot yet be run: 


instrU 
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instrl 

tlbj 

insnl 

milltest 

unix 

Newly available tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand_l_l 

xlu_compress_ 1 _ 1 

xlu_extract_l_l 

xlu_fie!d_l_l 

xlu_field_2_l 

xlu_field_3_l 

xlu_field_4J 

xlu_copyswap_l_J 

xlucopyswap_2_ 1 

xlu_copy swap_3_ 1 

xlucopy swap_4_ 1 

xlu_shufflemux_ 1 1 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstestO 

expriotest_0 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtestO 

cerberttest_0 

eventregtest_0 

exintbashtest_0 

cerb_registers_0 

cerberror_0 

testerinitO 

memmap_0 

doubleextestO 

cerberrtest_0 

cerbstarttest_0 

doublemctestO 

iorupttestj) 

ruptpintestj) 

iorupttest_0 

nbbashtest_0 

cerbraw_0 

cerbarbtests 

hep 11 tests 
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From: Guillermo A. Loyola [gmo@bilbo] 
Sent: Thursday, February 02, 1995 6:20 PM 
To: 'tbr@bilbo* 
Subject: Re: Reset cause 


Craig Hansen wrote: 

> 

> Upon reviewing my own documentation on this, I think the status quo 

> is acceptable: that the reset and/or clear bits read back as set 

> (1) at the end of a reset and/or clear. This facilitates the determination 

> of the cause of the transfer of control to the reset vector, 

But I though that the whole point was that in Euterpe those bits have 
nothing to do with determining the cause of the reset. Am I wrong 
on this? I was just talking to Sandeep and he had not understood that 
as Craig obviously hasn't either. 

I know what the TSA says, but my understanding is that that is not 
what Euterpe does, and although masking off the bits is a minimal 
burden on software, it is pointless and shouldn't be there. 

Gmo. 
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From: 


noel (Noel Verbiest) 

Thursday, February 02, 1995 6:54 PM 

'bill'; 'tbr'; 'wayne' 

'hestia'; 'dbulfer' 

Re: Main board power-up 


Sent: 

To: 

Cc: 


Subject: 


> From wayne Thu Feb 2 13:26:53 1995 

> Date: Thu, 2 Feb 1995 13:26:46 -0800 

> From: wayne (Wayne Freitas) 

> To: bill, tbr, noel 

> Subject: Main board power-up 

> Cc: hestia 

> Content -Length: 699 


> I began to look into the voltages levels during the power-up/down of 

> the main board with the DC-DC Module, and saw a pretty nasty overshoot 

> on the 3.3V. It looks like I'm going to have to get into this a 

> little farther, so I'm going to need some more data. To start I need 

> to know where would I get some information on what Euterpe and 

> Calliope look like upon power- up/down (lump circuit) . I would also 

> like to know if there a time requirement for the different power 

> planes to track during the power-up/down process (ie what happens if 

> +5v stays up 200ms after 3 . 3v drops)? One more thing, can someone 

> provide me with the absolute maximum values (or a swag) on Calliope and Euterpe. 


The 3.3V should be loaded with a minimum load (which, I seem to recall, is 10% or 4A, see 
the spec sheet) . If this minimum load is not there, the RO module will not regulate 
correctly. The other outputs do not need a minimum load. Could you do the test with this 
minimum load present. (I do not recall the exact value but seem to remember it was 10%). 
In order to evaluate the RO module from the component point of view, I have always used a 
load range from 2 5A (sleep mode of EU + CA) to 5 OA (EU and CA going full blast) . I have 
always assumed that there would be at least 25A flowing in the 3.3V supply. The regulation 
and efficiency have been optimized in that range. 

Noel@home 32 8 6003 


> 


> Wayne 
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From: Guillermo A. Loyola [gmo@bilbo] 

Sent: Thursday, February 02, 1995 7:06 PM 

To: 'dickson@dolphin'; 'craig@dolphin'; 'tbr@dolphin'; 'Sandeep Nijhawan' 

Cc: , gmo@dolphin'; 'jeffm@dolphin' 

Subject: Re: Reset cause 


The above is fine with me. Differentiating between a logic clear 
completion and a reset completion was what I was concerned about. 

But the description of what Euterpe implements clearly said that the differentiation comes 
from octlet 7 . 

Gmo. 
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From: jeffm (Jeff Marr) 

Sent: Thursday, February 02, 1995 7:1 1 PM 

To: 'lisar (Lisa Robinson)' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Subject: Update: Test Status - dcachenoalloc 

Looking at the dcachenoalloc dump, I noticed something strange. 

At time 37026, the signal CDwStbR17R18, bits 7:0, goes active. The 
CDwrtNdx is 7f4. This is the result of a store to the event mask. 
Doesn't this corrupt the dcache/dbuffer? 

The dump is in /u/tbr/euterpe/verilog/bsrc. 
jeffm 
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Subject: 


Sent: 

To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Thursday, February 02, 1995 8:12 PM 
'dbulfer' 

'graham 1 ; 'pandora' 

Re: Mixed signal module supply voltages 


For the Calliope modules, I agree with your suggestion that it makes sense to generate 
voltages other than 3.3V locally, using the two "analog" supplies that you describe. 
We should go to imminent decision on that aspect. 

I do think we also need to pay attention to relatively clean 3.3V supplies. 

Calliope consumes 17 amps at 3.3V, and we should aim for <10mV of noise and ripple. For 
Euterpe, the analog PLLs for clock generation/ recovery have been designed to be as noise 
immune as possible, but are certainly not as robust as ECL. 
Perhaps Rich M. would like to comment here. 

I would propose therefore that the power supply, in addition to providing two "analog" 
voltages of -9V and 2 8V, also focus on efficient inductive filtering of the 3.3V from the 
switching converter. 

Graham . 


> From dbulfer Thu Feb 2 17:27:37 1995 

> From: dbulfer (David Bulfer) 

> Subject: Re: Mixed signal module supply voltages 

> To: graham@MicroUnity.com (Graham Y. Mostyn) 

> Date: Thu, 2 Feb 95 17:29:12 PST 

> Cc : graham@MicroUnity.com, pandora 

> X-Mailer: ELM [version 2.3 PLll] 

> Content- Length: 2511 
> 

> On Jan 3 1 , Graham wrote : 

> > 

> > The module would certainly need internal supply bypassing to remove 

> > any noise picked up on the power bus between the supply card and the 

> > module . 

> > 

> > Assuming that we do so, my estimation would be that - prior to these 

> > filters - lOmV of wideband noise and ripple on the 3.3V, 5V and 12V 

> > supplies (used for the RF, audio and video) would be acceptable. 

> > 

> > The contingency VCO (-5V and 24V) needs extremely clean power 

> > - probably noise/ripple levels in the microvolt range. Local 

> > regulation is therefore necessary here; it may make sense to 

> > generate these voltages locally as well (as we do in Hestia) . 

> > 

> > It is difficult to give hard and fast figures, since the ripple and 

> > noise will to some extent be rejected by the differential circuits 

> > internal and external to Calliope. The amount of rejection (PSRR) 

> > is determined by the degree of component matching, and this will 

> > only be known following measurements on silicon. 

> > 
> 

> and on Jan 30, Graham wrote: 


> > 

> > At the Pandora meeting last Friday, I was to state which voltages an 

> > audio/video/RF module would require, assuming that all were provided 

> > centrally, and no voltage conversion was carried out on the module. 

> > 

> > The current design requires: 
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> > -5V, 3.3V, 5V, 12V and 24V. 

> > 

> > * The -5V and 24V are used only for the external VCO, and are 

> > expected to be short-term requirements only. 

> > However, we should plan to include them in prototypes. 

> > 

> > * The power on all supplies, except 3.3V, should not exceed in total 

> > about 4 watts. 

> > 
> 

> There are several conclusions that I can draw from this: 
> 

> 1) Calliope required a very clean power source. A switching supply 

> meant for the rest of the system is not adequate. 
> 

> 2) Calliope requires very little power of this quality. 
> 

> 3) Power distribution may inject more noise than is tolerable into 

> the analog systems. 
> 

> I believe that the only reasonable solution for critical analog supply 

> voltages is that they be locally generated. Considering the current 

> requirements, efficiency is unimportant (within reason, of course) . 
> 

> I propose that the smartest thing to do is supply you with 2 "analog" 

> voltages, that is, generated from a seperate linear supply. It looks 

> like +28 and -9 would satisfy all your needs. You could then use 

> filters and linear regulation to produce any of the voltages that you 

> need. 
> 

> If this is agreeable, I will post it as a DESISION IMMINENT. 

> Otherwise, I'm open to suggestions. 

> 

> Thanks, David 
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From: tbr 

Sent: Thursday, February 02, 1995 8:38 PM 

To: 'Guillermo A. Loyola' 

Subject: Re: Reset cause 

Follow Up Flag: Follow up 
Flag Status: Red 


Guillermo A. Loyola wrote (on Thu Feb 2): 


Craig Hansen wrote: 

> 

> Upon reviewing my own documentation on this, I think the status quo 

> is acceptable: that the reset and/or clear bits read back as set 

> (1) at the end of a reset and/or clear. This facilitates the determination 

> of the cause of the transfer of control to the reset vector, 

But I though that the whole point was that in Euterpe those bits have 
nothing to do with determining the cause of the reset. Am I wrong 
on this? I was just talking to Sandeep and he had not understood that 
as Craig obviously hasn't either. 

Well, if you write to octlet 6 with one of them set, you will cause a 
reset, so in that sense they certainly do. There are additional bits 
(in octlet 7) to indicate the cause in the case that the "reset" is 
really a machine check. 

I know what the TSA says, but my understanding is that that is not 
what Euterpe does, and although masking off the bits is a minimal 
burden on software, it is pointless and shouldn't be there. 

I don't think that the spec actually says these bits get cleared, only 
that the bits in octlet 7 get set on completion of the reset, (i'm 
lokking on p215 of the Apr 14,94 edition). My two concerns are 1. not 
to change the implementation unless we have to, and 2. making suree 
what we build will do what we need. I think I agree with craig that 
the current behavior should be acceptable. 

Tim 
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From: tbr 

Sent: Thursday, February 02, 1995 8:40 PM 

To: 'Guiilermo A. Loyola' 

Cc: 'craig@dolphin'; 'dickson@dolphin'; 'gmo@dolphin'; 'jeffm@dolphin'; 'Sandeep Nijhawan' 

Subject: Re: Reset cause 
Follow Up Flag: Follow up 

Flag Status: Red 


Guiilermo A. Loyola wrote (on Thu Feb 2): 


The above is fine with me. Differentiating between a logic clear 
completion and a reset completion was what I was concerned about. 

But the description of what Euterpe implements clearly said that the 
differentiation comes from octlet 7. 

But there i only 1 bit in octlet 7 (bit 63) to indicate either a reset 
or a clear is complete. 

Tim 
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From: Tim B. Robinson [tbr@dolphin] 

Sent: Thursday, February 02, 1 995 8:40 PM 

To: 'Guillermo A. Loyola' 

Cc: , craig@dolphin'; 'dickson@dolphin'; 'gmo@dolphin'; 'jeffm@dolphin'; 'Sandeep Nijhawan' 

Subject: Re: Reset cause 


Guillermo A. Loyola wrote (on Thu Feb 2) : 


The above is fine with me. Differentiating between a logic clear 
completion and a reset completion was what I was concerned about. 

But the description of what Euterpe implements clearly said that the 
differentiation comes from octlet 7 . 

But there i only 1 bit in octlet 7 (bit 63} to indicate either a reset or a clear is 
complete . 

Tim 
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From: Geert Rosseel [geert@rhea] 

Sent: Thursday, February 02, 1995 9:24 PM 

To: 'geert^rhea' 

Subject: pager log message 


page from geert to geert : 

pageme gmake V2E__HOST=gamorra geert_euterpegards start : Feb_02_13 : 52 end: 
Feb 02_19:22 exit 1 
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From: vanthof (vant) 

Sent: Thursday, February 02, 1995 9:55 PM 

To: Vikki(VikkiVu)' 

Cc: Vanthof (Dave Van't Hof)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)' 

Subject: MBdrcjobs 


Vikki, 

I'd like to propose holding off on any MB related drc runs until we've got the euterpe 
blocks pretty clean. The MB is needed for mnemosyne, but not for a while. 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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Subject: 


Sent: 
To: 

Cc: 


From: 


craig 

Thursday, February 02, 1995 10:27 PM 
'gmo@bilbo'; 'tbr@dolphin' 

'craig@dolphin'; 'dickson@dolphin'; 'gmo@dolphin'; 'jeffm@dolphin'; 'sandeep@dolphin' 
Re: Reset cause 


Octlet 7 has bits indicating whether a reset or clear is complete, and whether is 
completed "sucessfully . " Octlet 7, status, is used by something outside euterpe to 
determine when a reset or clear has been completed. Within euterpe, clearly, if you are 
executing instructions, the reset or clear has completed; octlet 6, control, tells you 
that a reset or clear as opposed to a machine check got you to the reset vector address. 


Craig 
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Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Thursday, February 02, 1995 11:24 PM 
'Geert Rosseel' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)' 
Re: topt "improvement" 


Geert Rosseel writes: 


> Hi Dave, 
> 

> There is an issue that we have not considered in our methodology. In 
>the DC- loading calculation, we should add the wire resistance (usually 
>sraall) to the load resistance to calculate the RI drop. 

> 

> I don't want to add this to the release topt yet, becuase I don' t 
>want to add any unnecessary perturbations. 

> 

> Is it possible to make a topt. new that does the above. I would just 
>take that and run it on euterpe to see what it changes ? 

> 

> Geert 

Yes, I can create a topt. new, but unfortunately, I'm not sure what you want me to do. I 
don't know how to add the resistance into the equation for DC Loading. All topt does now 
is add up numbers provided in the dcload file and compare to the driver total value (with 
the appropriate scaling) . So adding resistance into the equation is a bit confusing for 
me . 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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From: woody (Jay Tomlinson) 

Sent: Friday, February 03, 1995 12:22 AM 

To: 'mws (Mark Semmelmeyer)' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'lisar'; 'mws 1 ; 'tbr* 

Subject: Re: Update: Test Status - dcachenoalloc 


Mark Semmelmeyer wrote (on Thu Feb 2): 

> From jeffm Thu Feb 2 17:10:52 1995 

> Looking at the dcachenoalloc dump, I noticed something strange. 

> 

> At time 37026, the signal CDwStbR17Rl8, bits 7:0, goes active. The 

> CDwrtNdx is 7f4. This is the result of a store to the event mask. 

> Doesn't this corrupt the dcache/dbuffer? 

> 

> The dump is in /u/tbr/euterpe/verilog/bsrc. 

> 

> jeffm 

Is this SR store no-allocate? I wonder if this is confusing 
the write enable logic, which maybe is using cacheability instead 
of a true physical address decode to control CDwStbR17R18, 
then maybe no-alloc is getting rounded off to uncached to 
access SR but cached to access Dcache? Woody may know. 

The problem is that the equation was not updated from the early days when 
euterpe only had partial functionality. A careful de-morgan of the equation 
shows that "paEqlEvnt -OR- paEqlDbuf will enable the cdWe. The cacheable case 
shows up in another term. 

1 am surprised that we are just now noticing this. There is also a problem with 
the noallocate-hit case, it will *not* enable the cd write enable. 

woody 
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From: vanthof (vant) 

Sent: Friday, February 03, 1995 1:26 AM 

To: 'two (Fred Obermeier)' 

Cc: Vanthof (Dave Van't Hof)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)' 

Subject: euterpep drc errors 


Fred, 

There are still about 56 spacing violations in the space transformer. 
I have not looked at them yet. 

The error file is: 

/u/vanthof /compass /mobi/euterpe/tapeout /euterpep . err 

Could you look at this for me? 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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From: 
Sent: 
To: 

Subject: 


chip (Buffalo Chip) 

Friday, February 03, 1995 2:16 AM 

'billz' 

output of euterpe/verilog/bsrc/cc/.checkoutrc 


Fri Feb 3 00:11:10 PST 1995 (billz Fri, 3 Feb 1995 00:10:42 -0800) 
euterpe/verilog/bsrc/cc 

[Release BOM (V54.0) in euterpe/verilog/bsrc/cc (Fri Feb 3 00:11:10 PST 1995)] 


Dir 


euterpe/verilog/bsrc/cc 


BOM 54.0 


9.1 

1.17 

1.64 

32 .3 

1.16 

49.3 

28 .4 

28 .4 

40 .4 

51.2 

28 .16 

24 . 8 

1.15 

1.1 

14 .8 

5.10 

5.9 

5.1 


. checkoutrc 
Makefile 
cc. V 

cc . power . tab . top 
cc .ut 


cc_custom.pim 
cccount .pla 
cchexcount . pla 
cclatedirty . Veqn 
ccrcv. Veqn 
ccseq. Veqn 
ccstart.Veqn 
cctester . V 
cctester .h 
clean- request 
genpim.pl 
pimlib.pl 
power . tab . local 


(5.8) 


===> running euterpe/verilog/bsrc/cc/ . checkoutrc (Fri Feb 3 00:11:17 PST 
1995) <=== 
# 

# turn off pgroute 
# 

[ -f gards/nopgroute ] | | touch gards/nopg route # # use padtiles # [ -f gards/usepadtiles 
3 | | touch gards/usepadtiles # # use pifpack # [ -f gards/usepifpack ] | | touch 
gards/usepifpack # # insert an instance of the clock tree # [ -f gards/addclock ] j | touch 
gards/addclock # # disable old dcell placement obstruction # [ -f gards/noobs ] | | touch 
gards/noobs # # now do it . . . 
# 

gmake GARDS_DISPLAY=clio : 0 . 0 gards/cc- iter 
gmake[l]: Entering directory 

"* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc ' 
/usr/ local/bin/perl genpim.pl > pim.tmp 
mv pim.tmp gards /cc -pass 1 . pirn 
# 

# Get an initial sdl file. A manhattan approximation will be used # gmake 
GARDS_DISPLAY=clio:0.0 CYCLETIME=895 gards/cc-pass2 . sdl 

gmake [2J : Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/cc 1 
HOME=/n/auspex/sl0/chip/euterpe/ tools 

LM_LlCENSE_FILE=/n/auspex/slO/chip/euterpe/ tools/ si/ license/license. dat 
DISPLAY=clio: 0 . 0 SL_TOTAL__DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif gards/cc-passl . pirn -xrf gards/cc-passl .xrf - 
dff gards/cc-passl .dff -noHole \ 

-obstructionPdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa .pdl \ 
- obstruct ionCdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa . cdl \ 
-libraryPdl gards/cc-passlmacros .pdl -eel -tech mobi -sdl \ 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Preparing input files... 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa .pdl . . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Reading gards/cc-passl . dff . . . 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Fetching bounding box from 
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/n/auspex/slO/chip/euterpe/gards/sof a/sofa, cdl . . . 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Checking 

/n/auspex/sio/chip/euterpe/gards/sof a/sofa. cdl for fixed obstructions... 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Checking 

/n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl for Eel obstructions... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Processing the gards/cc-passl .pirn file... 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex : 63 rows (63 non-empty) ...spanning 44 
columns (20 maximum cells/row) ...for a total of 759 cells were written to "gards/cc- 
passl .pirn. pif . 0 ' . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (2108, 476) to (2510, 
671) [201 by 65 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 6634 ECL atoms placed in 

13065 [-0 obstructions] atom area [50.78% dense] #pim2pif .ex Version 0.2.41 Fri Jan 27 

10:03:57 PST 1995 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Concatenated output written to gards/cc- 
passl .pirn. pif HOME=/n/auspex/ slO/chip/euterpe/ tools 

LM_LICENSE_FILE= /n/auspex/slO/chip/euterpe/tools/ si/ license/ license .dat 
DISPLAY=clio: 0. 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack gards/cc-passl .pirn. pif - obstruct ionPdl 
/n/auspex/slO/chip/ euterpe/gards/sof a/sofa . pdl \ 

- obstructionCdl 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa . cdl \ 

-libraryPdl gards/cc-passlmacros .pdl -eel -tech mobi \ 

-trueSqueeze 4 0 -distance 6 -packBothEdges 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Preparing input files... 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Fetching bounding box from 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl . . . 
/n/auspex/slO/chip/euterpe/ tools/bin/pif pack : Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa, cdl . . . 
/n/auspex/slO/chip/euterpe/tools/bin/pif pack : Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. pdl . . . 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Processing pif section 0... 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Packing right edge... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: Final width 201 ECL atoms, squeezed out 0 
ECL atoms . . .which may include up to 3 0 ECL atoms of obstructions 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 63 rows (63 non-empty) ...spanning 19 
columns (20 maximum cells/row) ...for a total of 759 cells were written to "gards/cc- 
passl .pirn. pif .packed' . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: (2108, 476) to (2510, 
671) [201 by 65 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 6634 ECL atoms placed in 

13 065 [-1725 obstructions] atom area [58.50% dense] #pim2pif.ex Version 0.2.41 Fri Jan 27 
10:03:57 PST 1995 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Packing left edge... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: Final width 161 ECL atoms, squeezed out 
40 ECL atoms . . .which may include up to 30 ECL atoms of obstructions 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 63 rows (63 non-empty) ...spanning 19 
columns (19 maximum cells/row) ...for a total of 759 cells were written to "gards/cc- 
passl .pirn. pif .packed' . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (2188, 476) to (2510, 
671) [161 by 65 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 6634 ECL atoms placed in 

10465 [-1645 obstructions] atom area [75.22% dense] #pim2pif.ex Version 0.2.41 Fri Jan 27 
10:03:57 PST 1995 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Concatenated output written to gards/cc- 
passl .pirn . pif .packed mv gards/cc-passl .pirn. pif .packed gards/cc-passl .pif 
**** GPLACE cc-passl 
Fri Feb 3 00:12:11 PST 1995 

sed -e 1 siDESIGN_NAME! cc-passl ! ' -e " S ! EDIF_FILE ! cc-passl . sdl ! " \ 

-e ' s'CHIPROOT! /n/auspex/slO/chip/euterpei ' -e 1 s ! TECH_GPLACE i cc- 
passl . gplace .mobi2 34 ! ' \ 

-e 1 s!TECH_REDIT! cc-passl. redit.mobi234 1 ' \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/cc-passl. vrf rm -f 
gards/cc-passl. gplace. nic cd gards; if HOME=/n/auspex/ si 0/chip/euterpe/ tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/ license/license. dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -p -s cc-passl; then \ 

/usr/5bin/echo 'deletegroup use; ok' > cc-passl . gplace .nic; fi 
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/usr/5bin/echo ' readpif cc-passl .pif ; ok' >> 
gards/cc-passl .gplace.nic 

/usr/5bin/echo 'makeauto use; ok' >> 
gards/cc-passl . gplace .nic 

/usr/5bin/echo 1 iparara sweeps 0;' >> 
gards/cc-passl . gplace .nic 

/usr/5bin/echo 'iparara algorithm hper_net length ; ' >> 
gards/cc-passl . gplace .nic 

/usr/5bin/echo 'improve use; ok 1 » 
gards/cc-passl .gplace.nic 

/usr/5bin/echo 'writenof cc-passl .nof ; use; ok' >> 
gards/cc-passl .gplace.nic 

/usr/5bin/echo ' exitsave\nexitnosave 1 >> 
gards/cc-passl . gplace.nic 
( echo " cd * abspath * /gards ; \ 

HOME= /n/auspex/ si 0/ chip /euterpe/ tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/ tools/ sl/license/ license.dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke gplace cc-passl -listing cc- 
passl . gplace . lis -cmdin cc-passl . gplace . nic -colorin 
cc-passl .gplace .mobi234 -inbat 1" j \ 

/usr/local/bin/rexec ghidra sh && 
HOME=/n/auspex/ slO/chip/euterpe/ tools 

LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/license/license . dat 
DISPLAY=clio : 0 . 0 SLJTOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -sp gards/cc-passl) | | (mv gards/cc- 
passl. nof gards/cc-passl .nof . ERROR; rm -f cc-passl . nof ; false) 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gards conf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

Xlib: connection to "clio:0,0" refused by server 
Xlib: Client is not authorized to connect to Server 

Test: Error in opening display = clio:0.0 GARDS GPLACE 7.126 -- General Placer Copyright 
(c) 1995 SILVAR-LISCO. All rights reserved. 
Design: cc-passl Started at: 95/02/03 00:12:17 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components . . . 

Loading nets. . . 

Loading logical types... 

Processing physical types. . . 

Loading cell_types. . . 

Creating net-comp xref table... 

mv: gards/cc-passl .nof : Cannot access: No such file or directory 
gmake[2]: *** [gards/cc-passl . nof ] Error 1 
gmake[2]: Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/cc ' 
gmake[l]: *** [cc-base . short . nets] Error 1 
gmake [1] : Leaving directory 

v /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc ' 
gmake: *** [ccgards] Error 1 

[finished at Fri Feb 3 00:15:44 PST 1995 -- exit status 0] 
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From: lisar (Lisa Robinson) 

Sent: Friday, February 03, 1995 8:55 AM 

To: 'jeffm'; 'mws'; 'woody' 

Cc: 'billz'; 'dickson'; 'tbr' 

Subject: dcacheharder_V 

Dump is on nosferatu /s2/euterpe/verilog/bsrc 
Lisa R. 
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From: 


tbr 


Sent: 
To: 

Cc: 


Subject: 


Friday, February 03, 1995 10:37 AM 
'graham (Graham Y. Mostyn)' 
'dbulfer'; 'graham'; 'pandora' 
Re: Mixed signal module supply voltages 


Follow Up Flag: Follow up 
Flag Status: Red 

Graham Y. Mostyn wrote (on Thu Feb 2): 

Calliope consumes 17 amps at 3.3V, and we should aim for 
<10mV of noise and ripple. For Euterpe, the analog PLLs for 
clock generation/recovery have been designed to be 'as noise 
immune as possible, but are certainly not as robust as ECL. 
Perhaps Rich M. would like to comment here. 

The CMOS version of Euterpe will need an external PLL (per eariler 
email discussions where it was agreed there would be no PLL inside the 
chip). Can someone comment the anticipated power requirements for 
that function? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, February 03, 1995 10:37 AM 

'graham (Graham Y. Mostyn)' 

'dbulfer'; 'graham'; 'pandora' 

Re: Mixed signal module supply voltages 


Graham Y. Mostyn wrote (on Thu Feb 2) : 

Calliope consumes 17 amps at 3 . 3V, and we should aim for 
<10mV of noise and ripple. For Euterpe, the analog PLLs for 
clock generation/ recovery have been designed to be as noise 
immune as possible, but are certainly not as robust as ECL. 
Perhaps Rich M. would like to comment here. 

The CMOS version of Euterpe will need an external PLL (per eariler email discussions where 
it was agreed there would be no PLL inside the chip) . Can someone comment the anticipated 
power requirements for that function? 


Tim 
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From: bill (William Herndon) 

Sent: Friday, February 03, 1995 11:21 AM 

To: W 

Cc: 'graham'; 'rich' 

Subject: Re: Mixed signal module supply voltages 

> From tbr Fri Feb 3 08:39:44 1995 

> Date: Fri, 3 Feb 1995 08:36:46 -0800 

> From: tbr (Tim B. Robinson) 

> To: graham (Graham Y. Mostyn) 

> Cc: dbulfer, graham, pandora 

> Subject: Re: Mixed signal module supply voltages 

> Content-Length: 568 
> 

> 

> Graham Y. Mostyn wrote (on Thu Feb 2): 

> 

> Calliope consumes 17 amps at 3.3V, and we should aim for 

> <10mV of noise and ripple. For Euterpe, the analog PLLs for 

> clock generation/recovery have been designed to be as noise 

> immune as possible, but are certainly not as robust as ECL. 

> Perhaps Rich M. would like to comment here. 
> 

> The CMOS version of Euterpe will need an external PLL (per eariler 

> email discussions where it was agreed there would be no PLL inside the 

> chip). Can someone comment the anticipated power requirements for 

> that function? 

> 

>Tim 

> 
> 

I'm not clear on how we get quadrature signal for the iobyte.. 
i guess some sort of delay and don't ask for true quadrature., its possible 
theat we could make the delay frequency sensitive as a simple rc when it is 
near 90deg. 
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From: lisar (Lisa Robinson) 

Sent: Friday, February 03, 1995 12:19 PM 

To: 'woody (Jay Tomlinson)' 

Cc: 'for'; 'geert'; 'jeffm' 

Subject: dcacheharder_V 

Jay Tomlinson wrote (on Fri Feb 3): 

Lisa Robinson wrote (on Fri Feb 3): 
Dump is on nosferatu /s2/euterpe/verilog/bsrc 
Lisa R. 

Do you want me to continue working on dcacheannoying or would you rather I 
switch to this one (when 1 am not placing uu)? 

Since the critical path is though the verification, I would put 
local placements bottom of the list (Tim, Geert do you agree?). 
A glance (by Jeffm) of the likedriverlog 

may give some insight into the dcacheharder problem and then I think 
that you are the best to judge which should be debugged first. 

Lisa R. 
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From: dbulfer (David Bulfer) 

Sent: Friday, February 03, 1995 12:55 PM 

To: Tim B. Robinson' 

Cc: 'graham (Graham Y. Mostyn)'; 'pandora' 

Subject: Re: Mixed signal module supply voltages 


> Graham Y. Mostyn wrote (on Thu Feb 2) : 
> 

> Calliope consumes 17 amps at 3.3V, and we should aim for 

> <10mV of noise and ripple. For Euterpe, the analog PLLs for 

> clock generation/recovery have been designed to be as noise 

> immune as possible, but are certainly not as robust as ECL. 

> Perhaps Rich M. would like to comment here. 
> 

> The CMOS version of Euterpe will need an external PLL (per eariler 

> email discussions where it was agreed there would be no PLL inside the 

> chip) . Can someone comment the anticipated power requirements for 

> that function? 
> 

> Tim 


I don't know what frequencies required, but AMCC makes a PLL clock multiplier that 
generates TTL to 80 MHz and PECL to 300 MHz from an 10 MHz to 80 MHz source. This part 
consumes 800 mw. 


David 
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From: Brian Smith [brian@godzilla] 
Sent: Friday, February 03, 1995 2:29 PM 
To: , ptolemy@godzilla l 
Subject: Ptolemy pi I experiment 


Some results from the Ptolemy/Verilog experiment. 

The experiment was designed to investigate the timing of passing signals 
between A Verilog and Ptolemy simulation using sockets. I used Jeff Mar's 
low-level socket read/write routines and imbedded them into the Verilog 
and Ptolemy models, 

I chose the euterpe pll_eus_logic.V for the Verilog side and used a 
modified version of the integrators and VCO from Bob's reciever front-end 
model on the Ptolemy side. This is not an accurate model of the euterpe analog 
components but, that was not considered important for this experiment. 

The up,dn,vco, and rate signals were connected to a star I wrote to pass 
the signals across the socket. The star fires a blocking write/read for every 
particle it receives. The simulation is set up to oversample such that there 
are 20 particles for each complete vco cycle when the vco is at mid-range. The 
Verilog side makes a blocking write/read from within and 'always' block with a 
single unit delay so, it is locked into firing 20 times for each vco cycle. Each 
time this fires, a new update of the signals is passed up to the parent module. 

This makes for a good test case since it requires 20x oversampling of a 
simulated sofa signal and has a tight feedback path across the interface. 

The following results were obtained with Ptolemy running on adder and 
Verilog on godzilla, Verilog dumpfile enabled: 


Simulation times 


Test 1: Full simulation. Integrator just converges to within ~10mV of OV. 

20,000 Ptolemy ticks, 1,000 vco cycles: ~ 4 min 
Test 2: Ptolemy alone. Removed socket star. 

20,000 Ptoelmy ticks: 2:30 


Test 3: Stubbed off Verilog. Verilog simply calls socket as fast as possible 
using a unit delay with no digital logic simulation. Trying to get 
a handle on the socket interface overhead. 

20,000 Ptolemy ticks: 3:15 

Test 4: Verilog alone. Removed socket call. Replaced socket call with a 1 
unit delay toggle of vco. 

1 ,000 vco cycles: - 3 sec 
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Summary: 


Test 4 indicates that very little time is being spent simulating the digital 
logic so, I'm not even going to count it. 


Out of the total 240 seconds for Test 1 I estimate: 

Ptolemy sim time: 150 sec .. 62 % (From Test 2) 

Socket transfer overhead: 45 sec .. 19 % (From Test 3) 
Other interface overhead: 45 sec .. 19 % (see note) 


Note: This 45 seconds is the time that I can not account for in the 
total Test 1 sim time, after accounting for Test 2 and Test 3. 
I expect this is the time being spent for each of the simulators 
having to wait on the blocking reads while other scheduled sim 
events are being processed. Since I removed the socket star 
entirely in test 2, some of the missing time can be attributed 
to this code. 


It looks like Ptolemy is mostly pacing the simulation. The socket overhead 
doesn't look too bad when you consider that we are transfering an entire 
block in both directions 20 times for each vco cycle. Most simulations will 
not require a 20x oversample relative to the digital simulation and, will 
probably need to exchange signals at a rate lower than the sofa rate. 

Since we are already passing an entire block of data across the interface, 
I would expect the socket overhead to remain fixed as we start passing more 
signals. 


- Brian - 
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From: hopper (Mark Hofmann) 

Sent: Friday, February 03, 1995 2:48 PM 

To: 'geert (Geert Rosseel)'; 'wingard (Drew Wingard)'; 'torn (Thomas Laidig)'; 'ong (Warren R. 

Ong)'; 'two (Fred Obermeier)'; 'brianl (Brian Lee)' 
Subject: Standard Cell Automation 


Hi, 

Here are my meeting notes from this afternoon reformulated as a timeline. I'm still a 
little green on this .ht stuff. Could someone enter this into the proper place? (Where is 
the proper place?) Also, please expand with comments as appropriate. 

- thanks , 
hopper 

Automated CMOS standard cell creation 


Feb: 
finish: 
finish: 
start : 
start : 
start : 

Feb: 
start : 


complete CMOS XV lobe schematics (get names consistent) 
Parsche fully operational 

running Parsche to size devices in XS cells 
generating XS cells family 
laying out XV lobes 


work on CMOS Leafmold 


Feb 

start: Modify Celltest and add Tel/Massage front end 
to find worstcase conditions for each XS cell 

start: Develop timing characterization (including capacitance) for 
XS cells (end goal: timing lib for use by Synopsys) 


March: 
finish; 
finish: 
finish: 
start : 


first pass at XV lobe layouts 
CMOS leafmold 

Celltest/Tcl/Massage extension 
worstcase Spice simulations 


9 March: 

finish: Leafmold generation of XS cell family 
15 March: 

finish: worstcase Spice simulations 

22 March: 

finish: XS timing characterization 

By this date XS cell family fully characterized and ready to start 
Euterpe -> Cronus mapping 
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From: ras {Bob Sutherland) 

Sent: Friday, February 03, 1995 3:56 PM 

To: 'Brian Smith' 

Cc: 'ptolemy' 

Subject: Re: Ptolemy pll experiment 


> 

> Some results from the Ptolemy /Verilog experiment. 

> 

> The experiment was designed to investigate the timing of passing signals 

> between A Verilog and Ptolemy simulation using sockets. I used Jeff Mar's 

> low-level socket read/write routines and imbedded them into the Verilog 

> and Ptolemy models. 

> 

> I chose the euterpe pll_eus_logic.V for the Verilog side and used a 

> modified version of the integrators and VCO from Bob's reciever front-end 

> model on the Ptolemy side. This is not an accurate model of the euterpe analog 

> components but, that was not considered important for this experiment. 

> 

> The up.dn^co, and rate signals were connected to a star I wrote to pass 

> the signals across the socket. The star fires a blocking write/read for every 

> particle it receives. The simulation is set up to oversample such that there 

> are 20 particles for each complete vco cycle when the vco is at mid-range. The 

> Verilog side makes a blocking write/read from within and 'always' block with a 

> single unit delay so, it is locked into firing 20 times for each vco cycle. Each 

> time this fires, a new update of the signals is passed up to the parent module. 
> 

> This makes for a good test case since it requires 2 Ox oversampling of a 

> simulated sofa signal and has a tight feedback path across the interface. 

> 

> The following results were obtained with Ptolemy running on adder and 

> Verilog on godzilla, Verilog dumprile enabled: 

> 
> 

> Simulation times 

> 


> Test 1 : Full simulation. Integrator just converges to within ~10mV of 0V. 

> 

> 20,000 Ptolemy ticks, 1 ,000 vco cycles: ~ 4 min 

> 

> Test 2: Ptolemy alone. Removed socket star. 

> 

> 20,000 Ptoelmy ticks: 2:30 
> 

> 

> Test 3: Stubbed off Verilog. Verilog simply calls socket as fast as possible 

> using a unit delay with no digital logic simulation. Trying to get 

> a handle on the socket interface overhead. 

> 

> 20,000 Ptolemy ticks: 3:15 

> 

> Test 4: Verilog alone. Removed socket call. Replaced socket call with a 1 

> unit delay toggle of vco. 
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> 

> 1,000 vco cycles: ~3sec 

> 

> Summary: 

> 

> Test 4 indicates that very little time is being spent simulating the digital 

> logic so, I'm not even going to count it. 

> 
> 

> Out of the total 240 seconds for Test 1 I estimate: 

> 

> Ptolemy sim time: 150 sec .. 62 % (From Test 2) 

> Socket transfer overhead: 45 sec .. 19 % (From Test 3) 

> Other interface overhead: 45 sec .. 19 % (see note) 

> 
> 

> Note: This 45 seconds is the time that I can not account for in the 

> total Test 1 sim time, after accounting for Test 2 and Test 3. 

> I expect this is the time being spent for each of the simulators 

> having to wait on the blocking reads while other scheduled sim 

> events are being processed. Since I removed the socket star 

> entirely in test 2, some of the missing time can be attributed 

> to this code. 
> 

> 

> It looks like Ptolemy is mostly pacing the simulation. The socket overhead 

> doesn't look too bad when you consider that we are transfering an entire 

> block in both directions 20 times for each vco cycle. Most simulations will 

> not require a 20x oversample relative to the digital simulation and, will 

> probably need to exchange signals at a rate lower than the sofa rate. 
> 

> Since we are already passing an entire block of data across the interface, 

> I would expect the socket overhead to remain fixed as we start passing more 

> signals. 

> 
> 

> - Brian - 

> 
> 
> 
> 
> 


"If pigs could vote, the man with the slop bucket would be elected swineherd 
every time, no matter how much slaughtering he did on the side." 

-Orson Scott Card 

Robert A. Sutherland 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive 

Sunnyvale, CA 94089 

(408) 734-8100 

FAX (408) 734-8136 
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Cc: 

Subject: 


From: 
Sent: 
To: 


vanthof (vant) 

Friday, February 03, 1995 6:27 PM 

'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'hopper (Mark 
Hofmann)' 

'vanthof (Dave Van't Hof)'; 'two (Fred Obermeier)' 
drc/ivs status 


Latest drc/lvs status 
DRC: 

- space transformer drcs are back and clean. There are about 5 0 false 
drc errors associated with the openings for layer ID and copyright 
cells. These are due to the jagged edges along one side causing 
multiple trapezoids in the error file. Is it possible to straighten 
this edge? It would greatly simply the error file. 

- lower layers finished in about 63 hours. This is at least twice 
as fast as before parallelizing the drc flows, and gives us about 
two turns a week. 

- the floating poly check is now running and has passed a critical 

phase with flying colors. Never before has it completed STAGE 2 
(the flattening of input data) without filling the disk. It did 
so today with about 400 MB to spare. This is very good as a later 
stage will need almost all of it... In addition, we should see 
run times greatly reduced. 

- I'm in the process of releasing all the layout edits done to date 
to clean up drc errors. We did not get them all, but most of them. 
I guess when this is done a GETBOM will be needed in the snapshot 
so I can rerun the drc flows on this latest snapshot. 

The releasebom should be done in a couple of hours . 


- euterpe has a VSS/VDD short in it somewhere. I'm starting up a 
series of quadrant shorts checks. 

A lot of progress has been made, but there is still more to go. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim. h> Don't blame 
me, I didn't vote for him ! 


LVS: 


Thanks , 
Dave 
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From: Geert Rosseel [geert@rhea] 

Sent: Friday, February 03, 1995 6:45 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert: 

pageme gmake geert euterpegards start : Feb_03_l3 : 11 end: Peb_03_16:43 exit 
1 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wayne (Wayne Freitas) 

Friday, February 03, 1995 7:32 PM 

•bill'; 'tor*; 'noel' 

'hestia' 

Re: Main board power-up 


I still in the beginning here, but I think we have a problem on the DC-DC Modules 3.3V 
output. This is what I've done so far. Using the DC Load set to Resistance Mode I went 
through ~ 10 each settings ranging from lohm to .35ohms. Upon power-up using the AC-DC 
Module, I get an overshoot of ~1.6V for 1ms through the different resistance values. 
Measurement points were at Euterpe and by the DC-DC Module . 

I'm going to follow through with this, by contacting RO, and taking some more measurements 
under different conditions. I can really use that additional data as I asked before if we 
want to make these tests a little more realistic. 


Thanks , 


Wayne 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, February 03, 1995 11:40 PM 

'rich (Rich McCauley)' 

'bill'; 'geert'; 'd buffer'; 'graham* 

Re: Mixed signal module supply voltages 


Rich McCauley wrote (on Fri Feb 3) : 

It wasn't clear from the last round of email that an external PLL was actually 
necessary. My previous comment was that for the evaluation system why not just 
use a clock module and if the frequency needs to be adjusted, put in another 
one. However, if we use an external Pll we will probably need something like 
SOOmW to achieve a loop with octave tuning range and fmax ~400-500Mhz. 

It's a question of whether we ever want a CMOS euterpe to be able to interwork with a 
calliope module. If we do {an I think we do) , then we will have to have everything 
referenced to the same source and the CMOS euterpe module will have to use the same 
reference we provide to the Bipolar version. 


> I'm not clear on how we get quadrature signal for the iobyte. . 

> i guess some sort of delay and don't ask for true quadrature., its possible 

> theat we could make the delay frequency sensitive as a simple rc when it is 

> near 90deg. 
> 

I recommend a fixed internal string of gate delays. 

Bear in mind, that relative to the performance of the technology, we will want to push the 
Hermes interface as hard as we can. 


> > 


Tim 
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From: brianl (Brian Lee) 

Sent: Saturday, February 04, 1995 6:29 AM 

To: 'Lisa Robinson' 

Cc: 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; Vanthof (Dave Van't Hof)' 

Subject: Re: Build died 


Lisa Robinson writes: 


I heve paged brianl . 

cd /n/auspex/s23/euterpe-proteus-cp/exlax/motive ,- \ 

CHIPROOT=/n/auspex/s2 3/euterpe-proteus-cp . /mkmotive ealplqh3s4x2a 
ealporl4nf 8s3x3a ealporl5nf 8s3x4a ealporl6nf 8s3x4a ealporl7nf 8s3x4a ealporl8nf 8s3x4a 
eaf fbbdhl2sllx2a eaf f bbdhl6sl3x2a eaf fbdhl6sllx2a eaf f dhl6sllx2a ealdfl2s3x4a ealdf24s6x4a 
ealdf 36s9x4a | 


I | exit; \ 

mv motive. lib /n/auspex/s23/euterpe-proteus-cp/exlax/motive . lib 

Creating motive. lib mkmotive. awk error: missing clk_to_q time 

for 

cell eaf fbbdhl2sllx2a 
./ mkmotive. awk failed on cell eaf f bbdhl2sllx2a 
gmake[2]: *** [do-motive] Error 1 


I replied to lisa earlier, but since I was temporarily forced to use /usr/ucb/mail I 
didn't remember how to copy everyone else. 

I have been experiencing intermittent nfs problems since last night. I have also seen X 
connection problems in /u/chip builds trying to connect to clio. 

I believe that this error is because mkmotive. awk couldn't read the appropriate .tira file. 
It should (re-) run fine if it can manage to access all the required files. 


Brian L. 
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From: brianl (Brian Lee) 

Sent: Saturday, February 04, 1995 6:31 AM 

To: 'Tim B. Robinson' 

Cc: 'lisar (Lisa Robinson)'; 'geert (Geert Rosseel)'; 'vanthof (Dave Van't Hof)' 

Subject: Re: snapshot build 


Tim B. Robinson writes: 

Digging back through the log I noticed: 

cd /n/auspex/s23/euterpe-proteus-cp/exlax/dcload; 
CHIPROOT=/n/auspex/s23 /euterpe-proteus- cp 
/n/auspex/ s2 3 /euterpe-proteus- cp/exlax/misc/mkloadlib 
/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlw6xla. cur 
/n/auspex/s23/euterpe-proteus-cp/exlax/dcloa | d/eamemalrlwi6xla . cur 
/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwip6xla, cur 
/n/auspex/ s2 3 /euterpe-proteus-cp/exlax/dcload/eamemalrlwipr6xla. cur 
/n/auspex/ s2 3 /euterpe-proteus-cp/exlax/dcload/eamemalrlwir6xla. cur 
/n/auspex/ s2 3 /euterpe-proteus- c | p/exlax/dcload/eamemalrlwp6xla. cur 
/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwpr6xla.cur 
/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwr6xla . cur 

WARNING: setting some dcload data for eamem* ... 

Creating 

/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlw6xla. cur 
| Creating 

/n/auspex/ s2 3 /euterpe-proteus- cp/exlax/dcload/ eamemalrlwi6xla. cur . . 
j Creating 

/n/auspex/ s2 3 /euterpe-proteus- cp/exlax/dcload/eamemalrlwip6xla .cur . 
j Creating 

/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwipr6xla. cur 
| Creating 

/n/auspex/s2 3 /euterpe-proteus- cp/exlax/dcload/eamemalrlwir6xla. cur . 
| Creating 

/n/auspex/ s2 3 /euterpe-proteus- cp/exlax/dcload/eamemalrlwp6xla. cur . . 
j Creating 

/n/auspex/ s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwpr6xla. cur . 
| Creating 

/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwr6xla . cur . . 
I 

I What does the WARNING mean? Is there something missing here. 
I 

| Tim 
I 

This is just a reminder that we are setting some numbers by hand rather than simulating 
them . It is normal . 

Brian L . 
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From: Buffalo Chip [chip@rhea] 

Sent: Saturday, February 04, 1995 12:28 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 82.0 initiated by brianl completed e Sat Feb 4 
10:25:47 PST 1995 with exit status 2.. chip 
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From: geert (Geert Rosseel) 

Sent: Saturday, February 04, 1995 12:36 PM 

To: 'lisar*; tbr*; Vanthof 

Snapshot 

Can you let me know when the snapshot build is finished. 1 want 
to rebuild the LVS Euterpe after that. 

We discovered shorts arund the TLB, as Tom Vo had moved the TLB 
up but clock-connections had not been adjustes. That has been fixed now. 

Geert 
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From: lisar (Lisa Robinson) 

Sent: Saturday, February 04, 1995 1:13 PM 

To: 'geert'; 'tor'; Vanthof 

Cc: 'brianl' 

Subject: Build died 


I heve paged brianl. 

cd /n/auspex/s23/euterpe-proteus-cp/exlax/motive; \ CHIPROOT=/n/auspex/s23/euterpe- 
proteus-cp . /mkmotive ealplqh3s4x2a ealporl4nf 8s3x3a ealporlSnf 8s3x4a ealporl6nf 8s3x4a 
ealporl7nf 8s3x4a ealporl8nf 8s3x4a eaf f bbdhl2sllx2a eaf f bbdhl6sl3x2a eaf f bdhl6sllx2a 
eaf fdhl6sllx2a ealdfl2s3x4a ealdf24s6x4a ealdf36s9x4a 

| | exit; \ 

mv motive. lib /n/auspex/s23/euterpe-proteus-cp/exlax/motive . lib 

Creating motive. lib mkmotive.awk error: missing clk_to_q time for cell 

eaf fbbdhl2sllx2a ./mkmotive.awk failed on cell eaf f bbdhl2sllx2a 
gmake [2] : *** [do-motive] Error 1 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 04, 1995 1:47 PM 

'briani' 

'llisar*; 'geerf; Vanthof 
snapshot build 


Digging back through the log I noticed: 

cd /n/ auspex/ s2 3 /euterpe -proteus - cp/exlax/ dcload; 
CHIPROOT= /n/auspex/ s2 3 /euterpe-proteus- cp 
/n/auspex/ s23 /euterpe-proteus -cp/exlax/misc/mkloadlib 
/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlw6xla. cur 
/n/auspex/s23 /euterpe-proteus -cp/exlax/dcload/eamemalrlwi6xla. cur 
/n/ auspex/s2 3 /euterpe-proteus - cp/exlax/dcload/eamemalrlwip6xla . cur 
/n/auspex/s2 3 /euterpe-proteus -cp/exlax/dcload/eamemalrlwipr6xla. cur 
/n/auspex/s2 3 /euterpe-proteus -cp/exlax/dcload/eamemalrlwir6xla. cur 
/n/ auspex/s2 3 /euterpe-proteus -cp/exlax/dcload/eamemalrlwp6xla. cur 
/n/auspex/s2 3 /euterpe-proteus- cp/exlax/dcload/eamemalrlwpr6xla . cur 
/n/auspex/s23 /euterpe-proteus-cp/ exlax/dcload/ eamemalrlwr6xla . cur 
WARNING: setting some dcload data for eamera* . . . 

Creating /n/auspex/ s2 3 /euterpe -proteus-cp/exlax/dcload/eamemalrlw6xla . cur 
Creating /n/auspex/s23 /euterpe-proteus-cp/exlax/dcload/eamemalrlwi6xla . cur 
Creating 

/n/auspex/s2 3 /euterpe-proteus -cp/exlax/dcload/eamemalrlwip6xla. cur . . . 
Creating 

/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwipr6xla . cur . . . 
Creating 

/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwir6xla.cur . . . 
Creating /n/auspex/s23 /euterpe-proteus-cp/exlax/dcload/eamemalrlwp6xla . cur 

Creating 

/n/auspex/s23/euterpe-proteus-cp/exlax/dcload/eamemalrlwpr6xla.cur . . . 
Creating /n/auspex/s23 /euterpe-proteus- cp/exlax/dcload/eamemalrlwr6xla . cur 


What does the WARNING mean? Is there something missing here. 


Tim 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Saturday, February 04, 1995 4:40 PM 

'geerf 

'dbulfer' 

CMOS euterpe 


Follow Up Flag: Follow up 
Flag Status: Red 


I hear a rumor it might need a 4.4V supply. Is this true? 

If so we may have a hard time using a standard PSU in pandora. 

Can you confirm or deny please? 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, February 04, 1995 4:40 PM 

To: 'geert* 

Cc: 'aquifer" 

Subject: CMOS euterpe 


I hear a rumor it might need a 4.4V supply. Is this true? 

If so we may have a hard time using a standard PSU in pandora. 

Can you confirm or deny please? 

Tim 
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From: Geert Rosseel [geert@godzilla] 
Sent: Saturday, February 04, 1995 7:1 1 PM 

To: T billz@godzilla'; 'brianKggodzilla'; 'dickson@godzilla'; 'hopper@godzilla'; , mws@godzilla'; 
'tbr@godzilla'; 'woody@godzilla' 

Subject: nb BOM 107.0 

... does not place .. I think I can get around it , but I 
don't know the proper way to fix up nb placement, 

if my fix doesn't work, I'm going to be stuck, because my toplevel 
Euterpe.V wants this nb ... I'll keep you posted 

Geert 
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From: geert (Geert Rosseel) 

Sent: Saturday, February 04, 1 995 7: 1 9 PM 

To: 'tbr' 

Cc: 'dbulfer' 

Subject: Re: CMOS euterpe 

The spec for the CMOS Euterpe is 5V +/- 10%. For ou worst 
case simulations we use 4.4V . 

Geert 
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To: 


Cc: 

Subject: 


From: 


Sent: 


tbr 

Saturday, February 04, 1995 7:33 PM 

'geert (Geert Rosseel)' 

'dbulfer' 

Re: CMOS euterpe 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Feb 4): 

The spec for the CMOS Euterpe is 5V +/- 10%. For ou worst 
case simulations we use 4.4V . 

Phew! OK, thanks. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 04, 1995 7:33 PM 

'geert (Geert Rosseel)' 

'dbulfer' 

Re: CMOSeuterpe 


Geert Rosseel wrote (on Sat Feb 4) : 

The spec for the CMOS Euterpe is 5V +/- 10%. For ou worst 
case simulations we use 4.4V . 

Phew! OK, thanks. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Saturday, February 04, 1995 9:20 PM 
'Geert Rosseel' 

Vanthof (Dave Van't Hof)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson)'; 'hopper (Mark 

Hofmann)' 

Re: your mail 


Geert Rosseel writes: 
> 

> Snapshot 
> 

> Can you let me know when the snapshot build is finished. I want to 
>rebuild the LVS Euterpe after that . 

> 

> We discovered shorts arund the TLB, as Tom Vo had moved the TLB up but 
>c lock- connect ions had not been adjustes. That has been fixed now. 

> 

> Geert 

Does this mean the shorts checks in progress are not needed? 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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From: geert (Geert Rosseel) 

Sent: Saturday, February 04, 1995 1 1 :32 PM 

To: 'tbr@MicroUnity.com'; Vanthof 

Cc: 'brianl'; 'hopper' 

Subject: Re: snapshot rebuild 

I don't know about the missing clock-spar problem ... Tom and Kurt 
were looking at it, but I haven't heard from them yet 

i am ready to rebuild another small Euterpe. .. maybe I 
should do it anyway ..if the problem is not yet fixed, I'll 
just rerun it 

Geert 
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From: Mark Hofmann [hopper@godzilla] 

Sent: Sunday, February 05, 1995 2:41 AM 

To: 'Geert Rosseel' 

Cc: 'billz@godzilla'; 'brianl@godzilla'; 'dicksorKggodzilla'; , hopper@godzilla'; , mws@godzi!la'; 

'tbr@godzilla'; 'woody@godzilla' 
Subject: Re: nb BOM 107.0 


Geert Rosseel writes: 

. . . does not place . . I think I can get around it , but I 
don't know the proper way to fix up nb placement. 

if my fix doesn't work, I'm going to be stuck, because my toplevel 
Euterpe. V wants this nb ... I'll keep you posted . . 

Geert, 


Did you s o lve 

this one? 






It looks like 

there are some 

unplaced components . 

The 

. nof . ERROR 

rue 

says: 







TIT} -rj O DT 7V vr r\ ~~ 

FKooc»J-iA_JNJ < U > 

0 

0 

0 

0 

UNPLCD 

185 

2 

PRBSELB_N< 0 > 

0 

0 

0 

0 

UNPLCD 

21 

2 

PRBSELA_N< 1 > 

0 

0 

0 

0 

UNPLCD 

216 

2 

FK±3briiijJ3_rJ < 1 > 

0 

0 


0 

UNPLCD 

248 

2 

PRBSELA_N<2 > 

0 

0 

0 

0 

UNPLCD 

249 

2 

PRBSELB N<2> 

0 

0 

0 

0 

UNPLCD 

277 

2 

PRBSEIA N<3> 

0 

0 

0 

0 

UNPLCD 

278 

2 

PRBSELB N<3> 

0 

0 

0 

0 

UNPLCD 

305 

2 

CB3G N 

0 

0 

0 

0 

PART 

598 

9 

PRBSELA< 0 > 

1334 

0 

0 

0 

PART 

1188 

18 







PRBSELB<0> 

302 

0 

0 

0 

PART 

1231 

18 







PRBSELA<1> 

1334 

0 

0 

0 

PART 

1232 

18 

PRBSELB<1> 

302 

0 

0 

0 

PART 

1275 

18 







PRBSELA<2> 

1358 

0 

0 

0 

PART 

1276 

18 







PRBSELB<2> 

326 

0 

0 

0 

PART 

1316 

18 







PRBSELA<3> 

1358 

0 

0 

0 

PART 

1317 

18 







PRBSELB<3> 

326 

0 

0 

0 

PART 

1359 

18 







CB3G 

0 

0 

0 

0 

PART 

1640 

9 

PRBSELM1 N<0> 

0 

0 

0 

0 

PART 

2441 

3 

PRBSELM1 N<1> 

0 

0 

0 

0 

PART 

2478 

3 

PRBSELM1 N<2> 

0 

0 

0 

0 

PART 

2508 

3 

PRBSELM1 N<3> 

0 

0 

0 

0 

PART 

2537 
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PRBSELM1<0> 

0 

0 

0 

0 

PART 

3441 

3 

PRBSELM1<1> 

0 

0 

0 

0 

PART 

3484 

3 

PRBSELM1<2> 

0 

0 

0 

0 

PART 

3523 

3 

PRBSELM1<3> 

0 

0 

0 

a 

PART 

3559 


3 

Was an input .pirn file updated but not released? 
-hopper 
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From: geert (Geert Rosseel) 

Sent: Sunday, February 05, 1995 10:50 AM 

To: 'tbr'; Vanthof 

Subject: clock-spar 

Hi, 

Tim is right, I accidently had included eg on the exclude list. 
I will rebuild the small euterpe 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Sunday, February 05, 1995 12:04 PM 
'Geert Rosseel' 

Vanthof (Dave Van't Hof)'; 'tbr (Tim B. Robinson)' 
Re: clock-spar 


Geert Rosseel writes: 


> 


> 


> Hi, 


> Tim is right, I accidently had included eg on the exclude list. 

> I will rebuild the small euterpe 


> 


>Geert 


Thanks Geert. Just page me when the rebuild is done. I'll be out this morning and will 
start up a new drc/lvs set of runs when I get back. 

By the way, the upper drc 1 s now take less than 24 hours, the upsetting news is that there 
is still 4.8MB of errors (down from 20MB). 

I'll look at these when I get back later today. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim .h> Don't blame 
me, I didn't vote for him! 


Thanks, 
Dave 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Sunday, February 05, 1995 2:23 PM 
'wayne (Wayne Freitas)' 
'bill'; 'hestia'; 'noel' 
Main board power-up 


Follow Up Flag: Follow up 
Flag Status: Red 

Wayne Freitas wrote (on Thu Feb 2): 


I began to look into the voltages levels during the power-up/down of 
the main board with the DC-DC Module, and saw a pretty nasty overshoot 
on the 3.3V. It looks like I'm going to have to get into this a little 
farther, so I'm going to need some more data. To start I need to know 
where would I get some information on what Euterpe and Calliope 
look like upon power-up/down (lump circuit). I would also like to know 
if there a time requirement for the different power planes to track 
during the power-up/down process (ie what happens if +5v stays up 200ms 
after 3.3v drops)? One more thing, can someone provide me with the 
absolute maximum values (or a swag) on Calliope and Euterpe. 

For absolute max, do you simply mean over supply voltage and 
temperature, or over all knob settings too? Since we control current 
almost everywhere power should track close to linearly with supply 
voltage which would imply +10% at 3.6V relative to nominal. As far as 
knob settings go, if we did want to try turning knobs to the max, 
there would be a factor of about 7/6 on Euterpe and 7/5 on Calliope, 
though Calliope does have a few watts which are independent of knob 
setting. 


Tim 
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Subject: 


From: 


Sent: 
To: 

Cc: 


tbr (Tim B. Robinson) 

Sunday, February 05, 1995 2:23 PM 

'wayne (Wayne Freitas)' 

'bill'; 'hestia'; 'noel' 

Main board power-up 


Wayne Freitas wrote (on Thu Feb 2) : 


I began to look into the voltages levels during the power- up/down of 
the main board with the DC-DC Module, and saw a pretty nasty overshoot 
on the 3.3V. It looks like I'm going to have to get into this a little 
farther, so I'm going to need some more data. To start I need to know 
where would I get some information on what Euterpe and Calliope 
look like upon power- up/down (lump circuit) . I would also like to know 
if there a time requirement for the different power planes to track 
during the power-up/down process (ie what happens if +5v stays up 2 0 0ms 
after 3 . 3v drops)? One more thing, can someone provide me with the 
absolute maximum values (or a swag) on Calliope and Euterpe. 

For absolute max, do you simply mean over supply voltage and temperature, or over all knob 
settings too? Since we control current almost everywhere power should track close to 
linearly with supply voltage which would imply +10% at 3.6V relative to nominal. As far 
as knob settings go, if we did want to try turning knobs to the max, there would be a 
factor of about 7/6 on Euterpe and 7/5 on Calliope, though Calliope does have a few watts 
which are independent of knob setting. 


Tim 
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From: tbr 

Sent: Sunday, February 05, 1995 2:29 PM 

To: 'dbulfer (David Buffer)' 

Cc: 'graham (Graham Y. Mostyn)'; 'pandora' 

Subject: Re: Mixed signal module supply voltages 

Follow Up Flag: Follow up 

Flag Status: Red 


David Bulfer wrote (on Fri Feb 3): 

> 
> 

> Graham Y. Mostyn wrote (on Thu Feb 2): 

> 

> Calliope consumes 17 amps at 3.3V, and we should aim for 

> <1 OmV of noise and ripple. For Euterpe, the analog PLLs for 

> clock generation/recovery have been designed to be as noise 

> immune as possible, but are certainly not as robust as ECL. 

> Perhaps Rich M. would like to comment here. 
> 

> The CMOS version of Euterpe will need an external PLL (per eariler 

> email discussions where it was agreed there would be no PLL inside the 

> chip). Can someone comment the anticipated power requirements for 

> that function? 

> 

>Tim 

> 
> 

I don't know what frequencies required, but AMCC makes a PLL clock 
multiplier that generates TTL to 80 MHz and PECL to 300 MHz from an 
10 MHz to 80 MHz source. This part consumes 800 mw. 

Current target is 400MHz. 

Tim 
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From: tbr (Tim B. Robinson) 

Sent: Sunday, February 05, 1995 2:29 PM 

To: 'dbulfer (David Bulfer)' 

Cc: 'graham (Graham Y. Mostyn)'; 'pandora' 

Subject: Re: Mixed signal module supply voltages 


David Bulfer wrote (on Fri Feb 3): 


> Graham Y. Mostyn wrote (on Thu Feb 2) : 

> 

> Calliope consumes 17 amps at 3.3V, and we should aim for 

> <10mV of noise and ripple. For Euterpe, the analog PLLs for 

> clock generation/recovery have been designed to be as noise 

> immune as possible, but are certainly not as robust as ECL. 

> Perhaps Rich M. would like to comment here. 
> 

> The CMOS version of Euterpe will need an external PLL (per eariler 

> email discussions where it was agreed there would be no PLL inside the 

> chip) . Can someone comment the anticipated power requirements for 

> that function? 
> 

> Tim 


I don't know what frequencies required, but AMCC makes a PLL clock 
multiplier that generates TTL to 8 0 MHz and PECL to 3 00 MHz from an 
10 MHz to 80 MHz source. This part consumes 800 mw. 


Current target is 400MHz. 


Tim 
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From: geert (Geert Rosseel) 
Sent: Sunday, February 05, 1995 6:15 PM 
To: 'hopper'; 'lisar'; 'tbr'; 'vanthof ; Vo' 
Subject: New top-level Euterpe ready 

Hi Dave, 

I've build a new top-level Euterpe for LVS and DRC. It is 
in the same place as the previous one (euterpe snapshot). 

Geert 
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Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Sunday, February 05, 1995 8:13 PM 
•Geert Rosseel' 

'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; *tbr (Tim B. Robinson)'; 'vo (Tom Vo)' 
Re: New top-level Euterpe ready 


Geert Rosseel writes: 
> 

> Hi Dave, 

> 

> I've build a new top-level Euterpe for LVS and DRC. It is in the same 
>place as the previous one (euterpe snapshot) . 


Geert 


> 


Cool! I'll start the drc/lvs jobs up now. 

Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

2 55 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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From: lisar (Lisa Robinson) 
Sent: Sunday, February 05, 1 995 1 1 :43 PM 
To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 
Subject: Test Status 


Just an update 

BOM 218 running on Zycad - (register dependancy tests) 
BOM 223 running on IKOS 

Note: I cannot rebuild the stb tests to pick up the changes there so 
haven't re-run Itlb, nb.., reg_conflict. 

New business 


dcacheannoying_V 223 - Goes to X dump on nosferatu /s2 
dcachenoallocV 223 - Goes to X dump on nosferatu /s2 
dcachenoalloc_0 223 - Goes to bad dump on nosferatu /s2 

xlu_field_5_l 223 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/4295. 29774 

watchtest 223 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/4295.7973 - running in verilog 

icache_func_l 223 } 

icache_sz_4k_l 223 } traces in 5295.7249 Jeff these are for you! 

icache_sz_8k_l 223 } 

icache_sz_16k_l 223 } 

exl ltest 21 8 - Dump on nosferatu /s2 

uncruptharder_0 220 - Dump on nosferatu /s2 

dcache funcl 216 - hung dcachenoalloc NEW dump available ~tbr 

dcache_sz_l 6k_l 2 1 6 - went to bad very early in the test dump available for 2 1 8 but different nosferatu /s2 

ex 1 5test 22 3 - went to bad (expected?) trace in /n/rhodan/s 3 /euterpe/veri 1 og/bsrc/res/5295 .4 1 1 9 

exresgcmpritestl_0 } 

exresgexpitest 1 _0 } 
exresgmshrttest 1 _0 } 

exresgrotritestl J) } 223 - all went to bad (expected?) trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/5295.41 19 

exresgsh litest 1_0 } 

exresgshritestl_0 } 

exresgucmpritestl_0 } 

exresguexpitestl_0 } 

exresgushritestl_0 } 

Old Business 

barreM 21 8 - trace in /n/rhodan/s 3/euterpe/verilog/bsrc/res/l 295. 1 1 572, recreating with smaller test dram ex 

saaseasy 2 1 8 - Dump on nosferatu /s2 - Problem understood 

scaseasy 2 1 8 

dcache_sz_4k_ 1 2 1 6 - went to X } Traces in / n/rhodan/s3 /euterpe/veri log/bsrc/res/3 0 1 95 . 1 844 1 
dcache sz 8k 1 216 -went to X 
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exlocktest_0 


brmisstestj) RUNNING IN VERILOG NOW. 

bgateJJ 

dram load^config 1 0 } 

dram_store_unique_configl_0 } Test build problem (.config said 0) 
dramharder_config 1 _0 } 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 

nb slow 2 1 6 - Fix in test 

ltlb_l 216 -Fix in test 

reg_conflict 2 1 6 - Cute software "bug" 

exr 1 easy 2 1 4 - dump on /n/nosferatu/s2 . . . problem understood 


Have not yet been run: 


saastest_0 
scastest_0 

watchtest_0 

dcache_stress_l 
dcache_except 1 

nb_l 

nb_hermes_l 
nb_combo_l 

oc-synch_U 
oc_align_at 
alignldl 
align_st_l 

doubleextestj) 

cerberrtest 0 

cerbstarttest_0 

doublemctest_0 

iorupttest_0 

ruptpintestO 

brimmlongtest_0 

interrupt 1 

mem 1 

cachel 

exception_l 

bgatel 

barrell 

synch_l 

gtlb_miss_l 


dcache_perfjd 1 1 I 
dcache_perf_stlt_l 
dcache_perf_ldst 1 1_ 1 
dcach e _perf_l dst5t_ i 

addr_map_dram 

fVa_conflict_l 
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hermes_conflict_ 1 
dcache_conflict_l 
atom i cconfl ict_ 1 

interruptU 

exception_U 

bgate_U 

mem U 

tlb_U 

synchU 

barrelJU 

cache_U 

gtlb_miss_U 

Cannot yet be run: 


instr_U 
instr 1 
tlb_l 
insn_l 
nu litest 
unix 

Newly available tests 

xlurotatell 

xlu_rotate_2_l 

xluexpandll 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_fleld_2_l 

xlu_field_3_l 

xlu_field_4_l 

x lu_copyswap_ 1 _ 1 

x lucopy swap_2_ 1 

xlu_copyswap_3_ 1 

xlu_copy swap_4_ 1 

xlu_shufflemux_ 1 _1 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstestO 

expriotest_0 

canceltest^O 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

cerberrtest_0 

eventregtestO 

exintbashtest_0 

cerb_registers_0 

cerberror_0 

testerinit_0 

memmap_0 

doubleextest_0 

cerberrtest 0 

cerbstarttest_0 

doublemctest_0 
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iorupttestO 

ruptpintest 0 

iorupttestO 

nbbashtestO 

cerbraw_0 

cerbarbtests 

hcplltests 
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Sent: 
To: 

Subject: 


From: 


tbr 

Monday, February 06, 1995 10:53 AM 

'lisar' 

verfstat 


Follow Up Flag: Follow up 
Flag Status: Red 


What's the right incantation? I tried verfstst -s status in 
nosferatu:/s2/euterpe/ verify but it complained about the systax of the 
file and seems to have nothing after Feb 2. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Monday, February 06, 1995 12:52 PM 
'lisa' 

tgdb hangs trying to single-step 


When I run tgdb on ~gregg/stb/apps/tv/kernel it runs for about 10 minutes and then apears 
to hang. When I break I find that thread 0 is in the idle loop, thread 2 is trying to 
acquire a lock and thread 1 is in static_enqueue+236 trying to execute a smas64lai. When 
I try to do an "si" in thread 2 I never see another (tgdb) prompt. 

I have tgdb running under gdb in a shell window right now trying to single- step past this 
instruction, it apears stuck in execute_JLoop, if you'd like to check it out, otherwise it 
should be pretty easy to reproduce . 

I didn't notice any such problem on friday, and it seems like the same thing is happening 
in a stb-stable compiled app/kernel. The stable terp is able to execute both images past 
this point. 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Monday, February 06, 1995 1:16 PM 
'Istein' 

(Fwd) Sample of "STARTUP" (1/3) 


Forwarded mail from creemer@netcom.com (David Z. Creemer) 

To: go-alumni@asylum. sf . ca .us 
Hi all, 

Not to steal Jerry's thunder, but a sample of his book jusk came through my email box. 
Thought you might be interested. This is in three parts... 


Hey, y'all: 

Attached is an excerpt from one of our books that will be 
available on the net in April. I thought you'd like an early 
look. 


Dan 


Forwarded message 


Posted: Thu, 02 Feb 95 13:24:01 -0500 
Date: Thu, 02 Feb 95 13:24:01 -0500 
From: " " <startup@hmgate . hmco . com . umc . vax3 > 
To : maurerOhmgate . hmco . com . umc . vax3 
Subject: Auto -reply from startup@hmco.com 


STARTUP: A Silicon Valley Adventure 
by Jerry Kaplan 

to be published May 3, 1995 by Houghton Mifflin Company List price: $22.95 

Copyright 1994 Jerry Kaplan 
All rights reserved 

For permission to reproduce selections from this book, write to Permissions, Houghton 
Mifflin Company, 215 Park Avenue South, New York, New York, 10 003 

DESCRIPTIVE COPY 

Jerry Kaplan had a dream: he would redefine the known universe (and get very rich) by 
creating a new kind of computer. All he needed was sixty million dollars, a few hundred 
employees, a maniacal belief in his ability to win the Silicon Valley startup game. 

Kaplan, a well-known figure in the computer industry, founded GO Corporation in 1987, and 
for several years it was one of the hottest new ventures in the Valley. * Startup* tells 
the story of Kaplan's wild ride: 

how he assembled a brilliant but fractious team of engineers, software designers, and 


Cheers, 
-- David 


Forwarded message 


Date: Thu, 02 Feb 95 17:09:01 -0500 
From: Dan Maurer <maur er ©hmco . com > 
To : ... 

Subject: BOOK SAMPLE 
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investors; pioneered the emerging market for hand-held computers operated with a pen 
instead of a keyboard; and careened from crisis to crisis without ever losing his passion 
for his revolutionary idea. Along the way, Kaplan vividly recreates his encounters with 
eccentric employees, risk- addicted venture capitalists, and industry giants such as Bill 
Gates and John Sculley. And no one -- including Kaplan himself -- is spared his sharp wit 
and observant eye. 

Part con game, part show biz, part cutthroat competition, the computer business is an 
irresistible corporate soap opera. *Startup* is the first insider's account of what goes 
on behind the screen, and this entertaining book makes high- stakes capitalism a thrilling 
adventure . 

Jerry Kaplan hasn't learned his lesson. Not long after GO was sold to AT&T, he started a 
new company, this one devoted to reinventing on-line shopping. He and his family live near 
San Francisco. 

STARTUP will be available at bookstores everywhere, beginning in May 1995. To reserve a 

copy of the book directly from the publisher call 1- 

800-225-3362 

E-mail addressed to KAPLANJ@hmco.com will be forwarded to the author. 

The following is an uncorrected excerpt from the forthcoming book STARTUP to be published 
May 3, 1995 by Houghton Mifflin Company. The excerpt includes the Table of Contents, 
Prologue, Chapter 1, and the Index. 

TABLE OF CONTENTS 
Prologue 


1 . 

THE 

IDEA 

2. 

THE 

DEAL 

3 . 

THE 

COMPANY 

4 . 

THE 

FINANCING 

6. 

THE 

PROPOSAL 

7. 

THE 

PARTNER 

8. 

THE 

ANNOUNCEMENT 

9. 

THE 

WAR 

10. 

THE 

SPINOUT 

11. 

THE 

SWITCH 

12 . 

THE 

BUBBLE 

13 . 

THE 

REVERSAL 

14 . 

THE 

SHOWDOWN 


Epilogue 

Author's Note 

Chronology 

Appendix 

Glossary 

Index 


PROLOGUE 

Going, going, gone. The auction was over. The last of the obsolete personal 
computers, engineers' cubicles, and other debris of a corporate shipwreck was finally 
liquidated, sold piecemeal to a crowd of hopeful entrepreneurs looking for a bargain to 
help float their new ventures. A few curious bottom fishers hovered around the stacked 
remains of electronic pens, flat-panel displays, and plastic cases, picking over the 
artifacts of the dead company's product: a portable computer operated by a pen instead of 
a keyboard. 

To those of us who had pinned our hopes on this novel concept, the auction seemed 
vaguely sacrilegious, like watching treasure hunters dredge up human remains in their 
search for valuables. But it was clear to me, as the person who had launched the 
enterprise in the first place, that our passions and ideas had simply outlived their host, 
only to take root elsewhere in Silicon Valley. GO Corporation, and its offspring, EO, 
never quite found its market, but the concept of a pen computer remains as seductive as 
ever . 

Still, I had to accept that impossible, final truth: GO was gone. 
Six years, hundreds of jobs, $75 million- -all gone. If statistics were all that mattered, 
the story would end here. But behind the numbers lies a portrait of life at the edge of 
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the corporate universe, where the intrepid and the imprudent play a perpetual high- stakes 
game of creation. The goal is to establish new companies, magical engines of prosperity 
that spawn products, jobs, and wealth. The price of admission is a radical idea, one 
powerful enough to motivate people, attract investment, and focus society's energy on 
improving the way people work and play. But there is also a darker side to the story, a 
cautionary tale about what can happen to a young company when its timing is wrong, its 
technology too speculative, and its market not yet ready. 


As the winning bidders arranged to pick up their goods, I realized that the origin 
of GO could be traced back well before its founding in 1987, to a day in early 1979 when I 
first learned the truth about scientific progress from my Ph.D. dissertation advisor at 
the University of Pennsylvania. 

A shy Indian man with a shiny, balding head and an occasional stutter, Dr. Joshi 
was widely known for his brilliant work in artificial intelligence. Our weekly meetings to 
help me find a thesis topic were more like therapy sessions than academic discussions. 
Most of the time he would sit silently behind his desk, watching me wrestle with some 
difficult question at the blackboard. When I was particularly down, he would offer a 
cryptic bit of encouragement: "You're not wrong, you know." 

I had spent the past several months puzzling obsessively over an obscure problem 
in computational linguistics. One day, I explained to Dr. Joshi that I had searched the 
entire library for a clue to the solution, but without success. 

"Perhaps you should try a different approach, Jerry." 

"Like what?" 

He pointed to the clock on his wall. It was round with no numerals, only single 
tick marks for the hours. "What time is it?" 

" Four- thirty. " I thought he was pointing out that our hour was up. 
Instead, he walked over and rotated the clock a quarter turn to the right. 

"Now what time is it?" In its new position, the clock looked exactly as it had 
before, except for the position of the hands. 

11 S even f or ty - f i ve . " 

"Are you certain? Rotating a clock doesn't change the time, does it?" He had a 
point, but I didn't know what to make of it. "It only says four-thirty because someone 
decided that's what it means. What's on the wall is a dial with two hands, yet what you 
see is the time." I was still confused. He sighed, then continued. "All that's happened is 
that you've walked to the edge of the great mosaic of human knowledge. Up until now, 
you've been living in a world full of ideas and concepts that other people have set out 
for you. Now it's your turn. You get to design a piece of the mosaic and glue it down. It 
just has to fit with what else is there. And if you do a good job shaping your tile, it 
will be easier for the next person to fit his around yours." 

"You're saying that I've been looking for an answer when really I should be making 

one up?" 

He looked relieved. "Don't believe the bull about science being only an objective 
search for truth. It's not. Being a scientist also requires the skills of a politician. 
It's a struggle to define the terras, to guide the debate, and persuade others to see 
things your way. 

If you're the first one there" --again he pointed to the clock-- "you get to say what it is 
that others will see . " 

As I drove back to my apartment, the answer to my problem came to me. When I got 
inside, I called Dr. Joshi and gave him a hasty review of my thinking. I could hear the 
sound of chalk against blackboard as he worked out the logic. After a long silence, he 
finally spoke. 

"Beautiful. Now all you have to do is write it up and get out of here. 
There's nothing else I can teach you." 

Surely, I thought, he was being funny- -this was just his way of complimenting me 
on a good idea. "Come on, that's not true at all!" I said. 

"I suppose there *is* one other thing." He suddenly sounded more serious. 

"What's that?" 

"Just remember that ideas last longer than people or things. Your ideas will go 
further if you don't insist on going with them." 
You know, he was not wrong. 


CHAPTER ONE 
THE IDEA 

"Is this thing war surplus?" 
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"Huh? " 

The taxi driver didn't get it. We were racing down a narrow road in the suburbs of 
Boston, lurching from pothole to pothole. Each bump rattled the vehicle as though a shell 
had exploded nearby. The maroon logo on the door read "Veterans Taxi." The driver was 
vintage antiwar sixties- -short graying beard, ponytail held by a rubber band, and a 
Cossack hat with ear flaps as a concession to the bitter February cold. 

I was to meet Mitchell Kapor at Hanscom Field at nine A.M. sharp to check out his new toy, 
a personal jet. The trip from the Cambridge offices of Lotus Development Corporation- -the 
company he had founded in 1982, only five years earlier- -was supposed to take less than 
thirty minutes, but I was late, and lost. Mitchell had been clear that he wanted to depart 
promptly so we could arrive in San Francisco in time for his lunch appointment. 

The pavement widened without warning, and a stoplight signaled our reentry into 
the civilized world. The access road circled the field to the Butler Aviation terminal, 
where the private planes were parked. As instructed, we drove through an unobtrusive gate 
onto the field. Several small planes and a single jet sat in the passenger loading area, 
randomly scattered like animals maintaining a safe distance at a communal watering hole. I 
was relieved to see Mitchell just ahead of us, pulling suitcases and tote bags from the 
trunk of his dark gray 1984 Audi sedan. 

The unmarked jet was painted a nondescript brown and beige. A narrow gangway of 
four or five steep steps was carved out of its middle. 

Two large men in vaguely official dark blue outfits sporting epaulets and caps stood at 
ease on either side of the stairs, waiting for a limousine to deliver their new boss, the 
founder of the world's largest independent software company. They nervously eyed the two 
young men in blue jeans struggling toward them with bags hanging off both shoulders. 

"Can we get some help, please?" Mitchell bellowed. The two men froze momentarily, 
realizing that this young guy with shirt tails hanging out the back of his ski jacket was 
their man. They ran forward to relieve us of our luggage. 

"Good morning, Mr. Kapor," one of the crewmen said. 

"Call me Mitchell, and this is Jerry. He's hitching a ride today. 
We're splitting the gas." 

Mitchell laughed at his own joke. The operating cost of the craft was more than a 
thousand dollars an hour, much of which was high-grade jet fuel. The crewmen glanced at 
each other in disbelief and then introduced themselves as the pilot and copilot. 

We climbed the steps to find a cramped, tubular cabin decorated in dark brown 
fabric and wood paneling. It looked like a miniature old- fashioned men's club. There was 
a narrow aisle down the middle, just tall enough to stand in, with four seats along the 
right but only two seats along the left, followed by a couch long enough to lie down on. I 
imagined that the couch was there in case the jet's owner got lucky with a passenger- -a 
sort of airborne version of the mattress in back of a pickup truck. Mitchell, a devoted 
family man, wouldn't see it this way, but I was single and more attuned to such 
possibilities. A custom-made bar, with cutouts for bottles, displayed the varieties of 
hard liquor favored by the previous owners- -a bank whose executives had lived well before 
falling on harder times. There were also several Cuban cigars and packs of playing cards. 

"We can get rid of this stuff," Mitchell said. "Some Diet Coke and sugarless gum 
would be fine. " 

His face impassive, the pilot made a note. 


I first met Mitchell Kapor in 1984, when he wandered into my office unannounced 
and asked what artificial intelligence might mean to personal computers. I was a logical 
person to ask, having completed my Ph.D. in the field five years earlier. 

After graduating from Penn in 1979, I joined the research staff of Stanford 
University. Stanford had the pace and style of a country club, with research grants 
blowing in through every open window. After slaving away for years on graduate studies and 
working every odd job I could find to support myself, I felt as if I had died and gone to 
heaven. It was a dream job, with virtually no responsibilities other than to think about 
something interesting and write up my ideas once in a while. In the absence of any 
objective measures of success, the tenured professors in the computer science department 
took to alternative means of establishing their self -worth, mainly by infighting and 
collecting academic titles. After about a year and a half of pastoral bliss, I concluded 
it was unhealthy to retire at the vital age of twenty-eight. 

Early in 1981, everyone in sight was starting companies. I was unexpectedly 
offered the opportunity to join a new artificial intelligence company called Teknowledge, 
formed by a group of Stanford professors. Teknowledge built expert systems, computer 
programs that used knowledge gleaned from human experts to reason through complex 
problems, like diagnosing obscure forms of cancer. 

Accustomed to the academic environment, the researchers did their work on large, 
symbolic computers called LISP machines, oblivious of the personal computer revolution 
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taking place around them. The LISP machine was a classic boondoggle, built mainly under 
government grant and sold mainly to government research projects. An expensive/ high- 
performance computer, the LISP machine was to the personal computer what an F-15 fighter 
jet was to a Cessna 150. 

About two years into this endeavor, I suspected that similar results could be 
obtained at far lower cost on a personal computer. So I commandeered an IBM PC and started 
to write programs in my spare time. 

Within a few months, I had a number of promising prototypes up and running. In a 
remarkable coincidence, this was precisely when Mitchell came to visit, asking his 
question. 

We immediately hit it off, and talked about how to design a flexible database to 
manage personal information- -notes, ideas, to-do lists, phone messages, and the like- -as 
opposed to corporate data such as billing and inventory records. Mitchell offered me a 
consulting contract to develop these ideas into a product, working directly with him and 
another scientist named Ed Belove. I could work at home, in the wooded hills just west of 
Stanford, with occasional visits to Lotus's offices in Cambridge. 

For the next year or so, I lived and worked alone for extended periods, 
accompanied only by my cat, Critter P. Spats, the sole remaining evidence of a long-gone 
live- in girlfriend. Realizing that I might benefit from greater human contact, I took the 
proceeds from the sale of my Teknowledge stock and purchased a condominium on "crooked" 
Lombard Street in San Francisco. The constant flow of tourists down this cobbles toned 
landmark made me feel as if I had moved out of the wilderness onto the banks of the river 
of humanity. The cat loved the extra attention. 

Shuttling to Boston about once a month, I worked closely on the Lotus project with 
Mitchell and Ed. Our efforts resulted in a new type of program we dubbed a personal 
information manager, or PIM. As the project neared completion, we officially named the 
product Lotus Agenda. 

In February 1987, I was hitching a ride back to San Francisco on Mitchell's new jet to 
show him some extra features we'd added to the product at the last minute. 


Once we were on board, Mitchell started to search through his luggage. There were 
tote bags and briefcases everywhere. It was essential that the discriminating technophile 
travel with a variety of computers, portable phones, organizers, chargers, adapters, 
cords, and extra batteries, as well as the latest industry weeklies, computer magazines, 
and newspapers. I wondered if this was why Mitchell felt he needed his own j et- -checking 
all this stuff on a commercial flight would be a nightmare. When he was comfortably 
ensconced in a fortress of electronics, he took off his ski jacket, revealing his 
trademark outfit: 

a formal Hawaiian shirt (white background) over loose-fitting jeans. 

Mitchell was a big man, nearly six feet tall, and walked with a boyish bounce. He had a 
wave of dark hair with a touch of gray at the temples, betraying his thirty- six years. His 
two front teeth were slightly askew, giving him the faintest aspect of a woodchuck, which 
was seconded by his zeal and diligence. I could see that he was perspiring lightly from 
our hurried boarding. 

I looked like a junior Mitchell, the same height but twenty pounds lighter, though 
my hair was a bit more gray. The same ill-fitting designer jeans- -crafted for some 
platonic *GQ* ideal, not a son of Abraham- -curved under my waist and hung loose around my 
rear. 

Inevitably, the bottom button of my shirt fell above the belt buckle, leaving the 
shirttails free to wander their separate ways, revealing a roll of flesh. Like Mitchell, I 
was locked in perpetual battle with my weight, but the stakes were higher- -I couldn't 
afford to carry the girth of a typical middle-aged husband, for fear of never becoming 
one. 

We settled into the front pair of seats. 

"Put your seat back in the full upright position, and fasten your seat belt tight 
and low across your lap, ■ Mitchell admonished me with mock seriousness. 

We spent the next several minutes repeating verbatim the inescapable Big Brother 
rituals of the commercial airlines. We were soon laughing hysterically, and the pilots 
must have thought we were nuts. 

After taxiing a short distance, we were off the ground, climbing at a steep angle. We sat 
in silence for the next few minutes, watching the ground recede and feeling very regal. 

As soon as we leveled off, Mitchell pulled out his latest gadget-- the lightest, 
most powerful portable computer available. This remarkable machine, the Compaq 286, packed 
all the power of the most recent generation of desktop personal computers into a box about 
the size and weight of a small sewing machine. The numeric designation 286 was not 
selected at random. It indicated that the product contained at its core a microprocessor 
chip called the 8 02 86, designed and manufactured by Intel Corporation. 
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In the mid-1980s, computer cognoscenti had a penchant for substituting 
technobabble for plain talk. This served a useful purpose. 

Learning to use a computer- -much less to program one- -required a level of personal 
commitment commensurate with learning the piano, and a similar level of innate talent. It 
attracted people who had difficulty with the messy business of human relations, preferring 
instead the company of predictable and infinitely patient machines. This devotion was 
rewarded with valuable skills and friendships. Former wallflowers suddenly found 
themselves accepted into a new society of like-minded people who were more comfortable 
communicating through electronic mail than face to face. Now they could mask their 
awkwardness behind CPUs, RAMs, and modems. Geeks became chic. 

A secret language was the key to the club, like the lingo used by each generation 
of teenagers to identify kindred souls and exclude ignorant grownups. It made the members 
of this new caste feel special, smarter than everyone else. The embarrassment that 
ordinary people felt about their lack of computer knowledge only reinforced this feeling. 
But just knowing the model number of a computer wouldn't help you join the secret 
society--you had to know how to *pronounce* it. Nowhere was it written that 80286 should 
be read "eighty, two eighty-six," as opposed to "eight- zero- two- eight -six" or some other 
variation. Welcome to the club. 

"Bear with me," Mitchell said. "I've got to update my notes." He began to rifle 
through his pockets, pulling out small pieces of paper. 

Some were yellow stickies, some were pages ripped from a spiral-bound pocket notebook; 
there was even the stray napkin or gum wrapper. 

Mitchell was a prolific note taker, jotting down every interesting idea and reference 
within earshot. You never knew when he was going to strike out and appropriate the nearest 
writing implement and fragment of paper. 

On one particularly frantic occasion, I saw him tear the corner off a page of the *New 
York Times* and write in the L- shaped margin. 

Making sense of this motley collection of ideas, phone numbers, and reminders was 
Mitchell's passion. That's why he was so committed to Lotus Agenda- -he desperately needed 
the product himself. He powered up the Compaq 2 86 and waited while the machine went 
through its lengthy startup process. 

Mitchell rolled his eyes, whistled, and tapped his foot in exaggerated impatience. 
With Agenda finally up and running, he began typing in his accumulated scraps of notes 
with the efficiency of an executive secretary. 

"You know, this is really the pits, " he said. "It doubles the time it takes for me 
to keep organized. I wish there was some way for me to get all this stuff directly into 
the computer and skip the paper." 

That sounded like a challenge to me. 

"Look, Mitchell, it seems that the real question is how small and light you can 
make a portable computer . 11 

"Well, what are the largest components?" 

I thought for a second. "The disk drives are one problem. They 


End of forwarded mail from creemer@netcom.com (David Z. Creemer) 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

2 55 Caspian Drive, Sunnyvale, Ca 94 0 8 9-1015 gregg@microunity.com 
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From: woody (Jay Tomlinson) 

Sent: Monday, February 06, 1995 1:38 PM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tor 1 ; 'torn' 

Subject: euterpe/verilog/bsrc/at at.V at_control.pim atpadcd.Veqn 

Update of /p/cvsroot/euterpe/verilog/bsrc/at 

In directory staypuft ;/N/auspex/root/s20/woody/ch ip/euterpe/veri log/bsrc/at 

Modified Files: 

at.V at_control.pim atpadcd.Veqn 
Log Message: 

Fix internal at timing problem, internally a 2nd copy of paRl 1 [47] was added. 
Update placement. 

Local atgards results (at-final.topt.log): 

Atoms: count atom bjt isrc pld clock 

BJT Totals: 1491 9553 21958 14426 14032 6694 


Congratulations! No timing or DC Load violations! 
Includes exl ltest fix (erroneously called out bdownharder in last release). 
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Subject: 


Sent: 
To: 

Cc: 


From: 


dane (Dane Snow) 

Monday, February 06, 1995 4:56 PM 

'wayne' 

'hestia'; 'bill'; 'tbr'; 'noel' 
Re: Main board power-up 


> From wayne Fri Feb 3 17:33:10 1995 


> I still in the beginning here, but I think we have a problem on the 

> DC-DC Modules 3.3V output. This is what I've done so far. Using the 

> DC Load set to Resistance Mode I went through - 10 each settings 

> ranging from lohm to . 35ohms. Upon power-up using the AC-DC Module, I 

> get an overshoot of -1.6V for 1ms through the different resistance 

> values. Measurement points were at Euterpe and by the DC-DC Module. 

> I'm going to follow through with this, by contacting RO, and taking 

> some more measurements under different conditions. I can really use 

> that additional data as I asked before if we want to make these tests 

> a little more realistic. 


If it will help, I have a simulation of the eel current source behavior as the power 
supply is ramped up. The test circuit includes all of the relevant blocks from bgknobgen, 
a bellybutton, and a 1mA isrc (M=4 0) . 

When multiplied by an appropriate factor representing the total number of active isre's, 
this should give a reasonable representation of the load versus supply voltage 
characteristic. 


Wayne , 


Dane 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, February 06, 1 995 6:32 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/at BOM 47.0 initiated by woody completed @ Mon Feb 6 16:29:34 
PST 1995 with exit status 0 . . chip 


Exhibit Cll 


Page 114 of 55 


From: geert (Geert Rosseel) 

Sent: Monday, February 06, 1995 7:14 PM 

To: 'wampler' 

Cc: 'billz'; 'dickson'; 'geert'; 'mws'; 'tbr'; 'woody' 
Subject: New top-level Euterpe 

Hi Kurt, 

I've got a new top-level Euterpe . The main difference with the previous 
one is that I swapped sr and at placement. Can you route this please ? 

Geert 
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From: Geert Rosseel [geert@rhea] 

Sent: Monday, February 06, 1995 7:15 PM 

To: 'geeiKgrhea' 

Subject: pager fog, sender copy 


page from geert to wampler : 

New top-level Euterpe ready to route, geert 
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From: 


tbr 


Sent: 


Subject: 


To: 


Tuesday, February 07, 1995 12:18 AM 
■pmayer (Patricia Mayer)' 
Re: Latest status 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Mon Feb 6); 
Great! 

I was actually thinking it would be nice if we had 2 designs to layout 
in parallel. Perhaps the daughter card for Howard and even the 
Herminator for myself. 

Would it be appropriate to give him a copy of our Allegro standards 
(I just edited today.) and PCB Guidelines at this time? 

Seems like the bottle neck will be getting the netlists in. With that 
solved we ought to have pandora mnemo, pandora euterpe, hestia main, 
hestia daughter to go at. 

It will be fine to give him a copy of your document as soon as he has 
executed the NDA. You will need to keep carefiil track of what you 
hand over so we can be sure to get everything back if this is not 
permanent. In fact, we should have a general discussion about 
security/confidentiality etc right at the start. 


Tim 
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From: pmayer (Patricia Mayer) 

Sent: Tuesday, February 07, 1 995 1:10 AM 

To: 'tbr' 

Cc: 'pmayer' 

Subject: Re: Latest status 

> From tbr Mon Feb 622:17:51 1995 

> Date: Mon, 6 Feb 1995 22:17:48 -0800 

> From: tbr (Tim B. Robinson) 

> To: pmayer (Patricia Mayer) 

> Subject: Re: Latest status 

> Content-Length: 838 
> 

> 

> Patricia Mayer wrote (on Mon Feb 6): 

> Great! 

> I was actually thinking it would be nice if we had 2 designs to layout 

> in parallel. Perhaps the daughter card for Howard and even the 

> Herminator for myself. 

> Would it be appropriate to give him a copy of our Allegro standards 

> (I just edited today.) and PCB Guidelines at this time? 

> 

> Seems like the bottle neck will be getting the netlists in. With that 

> solved we ought to have pandora mnemo, pandora euterpe, hestia main, 

> hestia daughter to go at. 

Until then , Howard can review our parts process and help out in the part 
creation. 

> 

> It will be fine to give him a copy of your document as soon as he has 

> executed the NDA. You will need to keep careful track of what you 

> hand over so we can be sure to get everything back if this is not 

> permanent. In fact, we should have a general discussion about 

> security/confidentiality etc right at the start. 
> 

Right, I'll make up an "in-house" proprietory note book for him, not to 
leave the building. I'd like to have a meeting to review the documents 
with him, perhaps Wednesday atfernoon, with Glen, David, Philip, 
Wayne... Anyone else? 
-pattte 
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Subject: 


From: 


Sent: 

To: 

Cc: 


hopper (Mark Hofmann) 

Tuesday, February 07, 1995 2:53 AM 

'Jay Tomlinson' 

'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)' 
Re: pim2pif 


Jay Tomlinson writes: 

Currently uu is failing in pass2 with the following error from pim2pif (from 
/u/woody/chip/euterpe/verilog/bsrc/uu/gards/uu-pass2 .pim.warn) : 

FATAL: cell unbarryre4xO/uO [unbarryre4xO/uO XBOR3DH24S] at matrix position [77 1 
{empty. . .) ] , instance of xbor3dh24s, 
. . . is out of bounds (> maxy) 

. . .Requested x,y origin 3690 1196, 48x by 3y 
.. .Bounding box: (2, 2) (4777, 1195) 
. . . [ In units of most fundamental atom. ] 
. . .No obstructions hindered placement. 
...Constraint list: 

. . .unbarryre4x0/u0 [unbar ryre4x0/u0 XBOR3DH24S] [77 1 ] width 48 


In passl.pif, the cell is placed at (from 

/u/woody/chip/euterpe/verilog/bsrc/uu/gards/uu-passl .pif ) : 
unbarryre4x0/u0 0 0 crit 2 xbor3dhl6s 3690 713 
In passl.pof , the cell is placed at (from 

/u/woody/chip/euterpe/verilog/bsrc/uu/gards/uu-passl .pof ) : 
UNBARRYRE4X0/U0 7.44 0000 5.712000 AUTO 2 XBOR3DH16S 3 690 713 


Note that from passl to pass2 y changed from 713 to 1196. Any idea what 
happened and how I can work around this? Both .pirn files have 1 .yoffset 479' 

>From this message I would _guess_ that row 7 7 of UU is too wide for its 

space. Row 77 has width 4777 - 3690 or 1087 fundamental X- atoms in space. 

The log file should show how wide row 77 would be, assuming no obstructions. 

If that value is higher than 1087 then that's the problem. Probably Topt has powered up a 

cell from passl to pass2 and the row is now too wide to fit. 


-hopper 
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From: torn (Tom Laidig (tau)) 

Sent: Tuesday, February 07, 1995 7:33 AM 

To: Tim B. Robinson' 

Cc: 'ericm (Eric Murray)'; 'tau* 

Subject: Re: new auspex partitions 

Tim B. Robinson writes: 

| Eric Murray wrote (on Mon Feb 6): 

j i've installed the 9gb disks. 

j there's two regular partitions, /s7 and /s8, and 

| one mirrored partition /s48. 

| /s7 and /s8 are not striped, i did not stripe them 

j because when one spindle dies under striped partitions there 

| is more stuff to restore, the thought of having to restore 9gb 

j makes my head hurt. 


Yeah, the thought of having an 18GB failure group is scary from a few 
standpoints. I still vividly recall losing a bunch of work that hadn't 
had a chance to be captured on a backup... 


| /s48 is for the CVS tree. 

j i'd like to save one of the other two partitions to use for 

j moving filesystems off of more of the old 1 .35gb disks so we can 

j install more 9gb disks. 

| i gave /s47 (well most of it anyhow) to gmo for software build trees. 

|Thanks eric. Sounds good. Tom, when you move the repository over, 
jwill that include the software part of the tree also? 

I hadn't thought about it, but I certainly could. It looks as if 
collecting all the auspex cvs repositories (which excludes mnemosyne and 
terpsichore, which are on rama:/sl0) would fill s48 to 55%. This says I 
probably don't want to add very much else, if anything. 

Do you know who the keeper(s) of the software tree is, so I can 
coordinate the move? Fortunately, the move can be done in stages, with 
only one directory tree at a time being unavailable. 


ooooO Ooooo 

( J (_) 
\( tau )/ 

O O 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, February 07, 1995 8:51 AM 

To: 'Bob Sutherland' 

Cc: 'graham (Graham Y. Mostyn)'; 'fwo (Fred Obermeier)'; Vant'; 'brianl (Brian Lee)'; Tim B, Robinson' 
Subject: Re: CAD resources 

Bob Sutherland writes: 
Well, it appears the chronic Ptolemy resource problem has again 
arisen. While discussing with BrianL about when he expects to be able 
to spend some dedicated time to Ptolemy, it became apparent that this 
'short-term' overload would continue throughout the year. 

I think we need to get more people in to support the tool development 
we need. Brian Smith expects to be available for continuing work on 
the socket interface so there is progress, but Dave Vanthof has not 
had any chance at all to address the Concept/ptcl link, and BrianL has 
been on-and-off on the edif link to the point where every week I have 
to re-expose myself to the last blockage before proceeding. 

So. Ideas. 

Bob, 

With CMOS Euterpe coming up as soon as Euterpe tapes out, you are correct, 
our CAD resources are strained. I propose two solutions: Fred should have 
some time to help out. He is working Csyn/Celltest of Euterpe and massage 
extensions, but can probably spare some cycles to look at the Ptolemy 
interfaces. Brianl will be avialable part time, but is working on 
bringing the CMOS timing libraries on line. Dave needs to spend his time 
getting Euterpe DRC and LVS clean. My second proposal is to try to attract 
someone from the Berkeley Ptolemy group to come here, either on a 
consulting basis or full-time. Fred has a contact there whom he will talk with. 

-hopper 
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From: lisar (Lisa Robinson) 
Sent: Tuesday, February 07, 1995 9:28 AM 
To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'for'; 'woody' 
Subject: Test Status 

BOM 218 running on Zycad - (register dependancy tests) 
BOM 223 running on IKOS 

Note: ltlb_l and reg_conflict_l both ran okay 

New business 


regdepend_r 1 9204_0 2 1 8 - Miscompare trace in /n/aphrodite/s3/euterpe/verilog/bsrc/res/3295. 1 8357 
regdepend_r 1 93 68_0 2 1 8 - Miscomparetrace in /n/aphrodite/s3/euterpe/verilog/bsrc/res/3295 . 1 83 57 

dcache_sz_16kj 223 - X - trace on rhodan /s3 6295.15970 

icache_func_l 223 New trace in 6295.1 8837 on rhodan /s3 

dcacheharder2_0 223 - Bad - trace on rhodan /s3 6295 . 1 863 9 
nbhiprio^O 223 - Bad - trace on rhodan /s3 6295 . 1 863 9 

nb_slow 223 - Running a longgggg time trace on rhodan /s3 7295. 1 9 1 05 

watchtest 223 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/4295.7973 - running in verilog 

So far going to bad - Jeff could you take a look at the wrap.log on nosferatu /s2. 

Old Business 

brmisstestj) 223 - X dump on rhodan /s3 

dcacheannoying^V 223 - Goes to X dump on nosferatu /s2 
dcachenoalloc_V 223 - Goes to X dump on nosferatu /s2 
dcachenoallocO 223 - Goes to bad dump on nosferatu /s2 

xlu_field_5_l 223 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/4295.29774 

icache_sz_4k_l 223 } traces in 5295.7249 Jeff these are for you! 
icache_sz_8k_l 223 } 
icache_sz_16k_l 223 } 

ex 1 1 test 2 1 8 - Dump on nosferatu /s2 
uncruptharder 0 220 - Dump on nosferatu /s2 

dcache June _1 2 1 6 - hung dcachenoalloc NEW dump available ~tbr 

ex 1 5test 223 - went to bad (expected) trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/5295 .4 1 1 9 

exresgcmpr itest 1 _0 } 
exresgexpitest 1 _0 } 
exresgmshritest 1 0 } 

exresgrotritestl O } 223 - all went to bad (expected) trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/5295.41 19 
exresgshlitestlj) } 
exresgshritestl_0 } 
exresgucmpritestl_0 } 
_0 } 
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exresgushritestl 0 } 


barrel_ 1 2 1 8 - trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/ 1295.1 1572, recreating with smaller test dramex 

saaseasy 2 1 8 - Dump on nosferatu /s2 - Problem understood 

scaseasy 218 

dcache_sz_4k_l 2 1 6 - went to X } Traces in /n/rhodan/s3/euterpe/veri log/bsrc/res/30 1 95 . 1 844 1 
dcache_sz_8k_l 2 1 6 - went to X 

exlocktest_0 

bgate_U 

dram_load_configl_0 } 

dram_store_unique_configl_0 } Test build problem (.config said 0) 
dramharder_configl_0 } 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 
exr 1 easy 2 1 4 - dump on /n/nosferatu/s2 ... problem understood 

Have not yet been run: 


saastest_0 
scastest_0 

watchtest_0 

dcache_stress_l 
dcache_except_l 

nbj 

nb_hermes_l 
nb_combo_l 

oc-synch_U 
ocalignat 
align_ld_l 
align_st_l 

doubleextestO 

cerberrtest_0 

cerbstarttest_0 

doublemctestO 

iorupttest_0 

ruptpintest_0 

brimmlongtestO 

interruptl 

mem_l 

cache_l 

exceptional 

bgate_l 

barrel_l 

synch_l 

gtlb_miss_l 

dcache_perf_ld 1 1_ 1 
dcache_perf_st 1 1_ 1 
dcache_perf_ldst 1 t_l 
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dcache„perf_ldst5t_l 


addr_map_dram 

fva_conflict_l 
hermes_conflict 1 
dcache_conflict_I 
atomic_conflict_l 

interrupt_U 

exception_U 

bgate_U 

rnemU 

tlbU 

synchU 

barrel_U 

cache_U 

gtlb_miss_U 

Cannot yet be run: 

instrU 

instrl 

tlbj 

insnl 

nu litest 

unix 

Newly available tests 


xlu_rotate_l_l 

xlujrotate_2_l 

xlu_expand_l_l 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_field„2_l 

xlu_fleld_3_I 

xlu_field_4_l 

xlu_copy swap_ 1 1 

xlu_copy swap_2_ 1 

xlu_copy swap_3_ 1 

xlu_copy swap_4 1 

xlu_shufflemux_ 1_1 

xluselectll 

Not yet implemented: 


brcolltestj) 

brcrosstest_0 

expriotest_0 

canceltestO 

hermtotestO 

cerbtotest_0 

hermerrtest_0 

cerberrtest_0 

eventregtest_0 

exintbashtest_0 

cerb_registers 0 

cerberror_0 

testerinit_0 
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memmap 0 

doubleextest_0 

cerberrtestO 

cerbstarttest_0 

doublemctestO 

iorupttest_0 

ruptpintest_0 

iorupttestO 

nbbashtest_0 

cerbraw_0 

cerbarbtests 

hcplltests 
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Subject: 


Sent: 

To: 

Cc: 


From: 


woody (Jay Tomlinson) 

Tuesday, February 07, 1995 10:11 AM 

'hopper' 

'geert'; 'tbr' 

pim2pif 


hopper , 


Currently uu is failing in pass2 with the following error from pim2pif (from 
/u/woody/chip/euterpe/verilog/bsrc/uu/gards/uu-pass2 . pirn . warn) : 

FATAL: cell unbarryre4x0/u0 [unbarryre4x0/u0 XBOR3DH24S] at matrix position [77 1 
(empty...)], instance of xbor3dh24s, ...is out of bounds (> maxy) ...Requested x,y origin 
3690 1196, 48x by 3y ...Bounding box: (2, 2) (4777, 1195) ...[ In units of most 
fundamental atom. ] ...No obstructions hindered placement. 
...Constraint list: 

. . .unbarryre4x0/u0 [unbar ryre4x0/u0 XBOR3DH24S] [77 1 ] width 48 


In passl.pif , the cell is placed at (from 

/u/woody/chip/euterpe/verilog/bsrc/uu/gards/uu-passl . pif ) : 
unbar ryre4x0/u0 0 0 crit 2 xbor3dhl6s 3690 713 
In passl.pof, the cell is placed at (from 

/u/woody/chip/euterpe/verilog/bsrc/uu/gards/uu-passl .pof ) : 
UNBARRYRE4X0/U0 7.440000 5.712000 AUTO 2 XBOR3DH16S 3690 713 


Note that from passl to pass2 y changed from 713 to 1196. Any idea what happened and how I 
can work around this? Both .pirn files have ' .yoffset 479' 


Jay 
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From: geert (Geert Rosseel) 

Sent: Tuesday, February 07, 1 995 1 0: 1 5 AM 

To: 'hopper'; Vanthof@MicroUnity.com' 

Cc: 'dickson'; 'hopper@MicroUnity.com'; 'sysadm'; 'torn'; Vant'; 'wampler' 
Subject: Re: What happened to /n/auspex/s34 ? 

> It definitely looks like automounter problems. 

I has similar problems at the end of last week. I could 
not get to /n/ghidra/s3 from several SPARC 10's . Not 
good since that is where I build Euterpe . 

Geert 
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From: 
Sent: 
To: 


rmm (Richard Meller) 

Tuesday, February 07, 1995 12:34 PM 

'hestia'; 'bill' 


Lee Hill (EMC consultant) was here on Fri . 2/3/95. The analog hardware group and Bill 
Herndon and Wayne Freitas met with Lee to discuss the Hestia PCB . Lee brought up a 
handfull of issues regarding the present PCB: 

1) Lee beleaves we will need some sort of positive gasket contact 
between the PCB grounds and the aluminum housing for adequate shielding 
of the compartments. 

2) In the audio section we are returning the signal to 
(Chassis?) ground. Lee 

indicated that there will be a ground loop when our box gets connected 
to anything else with an earth ground. This will cause degradation of 
the audio quality. 

3) In the phone section the input trace goes above chassis ground 
which might be a problem (lightning strikes) as far as dialectric 
breakdown is concerned. Later in the meeting Lee sort of reversed his 
opinion and said that it might be OK because fr4 has alot of dielectric 
strength. 

4) Lee noticed a few high impedacnce traces which are not 
referenced to a 

ground near the output RJ11 connectors. These traces will act like 
radiators; any RF voltages > lmv leaving the box will cause failure of 
FCC EMC requirements. 

5) The AC /DC module has long traces at input /output before seeing any 
decoupling capacitors. These traces will act as radiators. 


Lee seemed skeptical of the present board being able to achieve the 100 dB desired 
isolation from Vcc to input signal line of the box. 

The above is what I have in my notes. Anyone else in the meeting who might have somthing 
to add feel free. 


Rick M. 
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Subject: 


From: 


Sent: 

To: 

Cc: 


lisar (Lisa Robinson) 

Tuesday, February 07, 1995 3:39 PM 

'craig'; 'tbr' 

'bobm'; 'dickson'; 'euterpe'; 'jeffm' 
double machine check bit 


According to the TSA and the Euterpe MicroArchitecture document bit 60 of oclet 7 is the 
double machine check bit . 

Calliope and the current implementation of Euterpe use this bit to indicate low voltage or 
temperature . 

What is bit 59 in Euterpe oclet 7 intended to be used for (current documentation says this 
bit is reserved for indicating additional causes of reset) and could it be used for double 
machine check. 


Lisa R. 


Exhibit Cll 


Page 129 of 55 


Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Tuesday, February 07, 1995 6:26 PM 

'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)' 

Vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; Vo (Tom Vo)' 
A bunch of new layouts ready for a getbom in snapshot 


Hello, 


I've checked in and released a bunch of layouts for euterpe which need to be updated. 
Once this is done, then Geert, can you regenerate the baseplate and new layout files for 
me? Then I can start up another fullchip drc run. 

This time the metals should be very clean compared to previous runs. 
Please let me know when this is available so I can start up the drc runs. 
Paging can be done at anytime. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him I 


Thanks , 
Dave 
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To: 


Subject: 


From: 


Sent: 


tbr 

Tuesday, February 07, 1995 11:37 PM 
lisar" 

forwarded message from Mark Hofmann 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Return-Path: <hopper> 

Received: from tomato.microunity.com by gaea.microunity.com (4.1 /muse 1.3) 

id AA19130; Tue, 7 Feb 95 14:51:43 PST 
Received: from localhost by tomato.microunity.com (8.6.4/muse-sw.3) 

id OAA01880; Tue, 7 Feb 1995 14:51:24 -0800 
Message-Id: < 1 9950207225 1 .OAAO 1 880@tomato.microunity.com> 

In-Reply-To: < 1995020721 45 .NAA 148 10@narcissus.microunity.com>; from "Bob Sutherland" at Feb 7, 95 1:45 pm 

X-Mailer : ELM [version 2.3 PL 1 1 ] 

From: hopper (Mark Hofmann) 

To: ras@MicroUnity.com (Bob Sutherland) 

Cc: graham (Graham Y. Mostyn), two (Fred Obermeier), vant, brianl (Brian Lee), 

tbr (Tim B. Robinson) 
Subject: Re: CAD resources 
Date: Tue, 7 Feb 95 14:51:23 GMT 

Bob Sutherland writes: 
Well, it appears the chronic Ptolemy resource problem has again 
arisen. While discussing with BrianL about when he expects to be able 
to spend some dedicated time to Ptolemy, it became apparent that this 
'short-term' overload would continue throughout the year. 

I think we need to get more people in to support the tool development 
we need. Brian Smith expects to be available for continuing work on 
the socket interface so there is progress, but Dave Vanthof has not 
had any chance at all to address the Concept/ptcl link, and BrianL has 
been on-and-off on the edif link to the point where every week I have 
to re-expose myself to the last blockage before proceeding. 

So. Ideas. 

Bob, 

With CMOS Euterpe coming up as soon as Euterpe tapes out, you are correct, 
our CAD resources are strained. I propose two solutions: Fred should have 
some time to help out. He is working Csyn/Celltest of Euterpe and massage 
extensions, but can probably spare some cycles to look at the Ptolemy 
interfaces. Brianl will be avialable part time, but is working on 
bringing the CMOS timing libraries on line. Dave needs to spend his time 
getting Euterpe DRC and LVS clean. My second proposal is to try to attract 
someone from the Berkeley Ptolemy group to come here, either on a 
consulting basis or full-time. Fred has a contact there whom he will talk with. 

- -hopper 

End of forwarded message 
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Sent: 


Cc: 


From: 


To: 


lisar (Lisa Robinson) 

Wednesday, February 08, 1995 12:08 AM 
'billz'; 'dickson'; 'mws'; 'woody' 
'doi'; 'jeffm'; 'tbr' 


Subject: euterpe verilog targets 


You will need to pick up the newly checked in hc/hc_device.V if you need to 

run a verilog simulation with the he pli. Eg all of the _0_sim _v_sim _l_sim targets etc. 

The parameter startup_cycles was changed to be startup-cycles in the latest 

build of verilog with the he pli. 


Lisa R. 
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From: 


tbr 


To: 


Sent: 


Subject: 


Wednesday, February 08, 1995 12:35 AM 

'pmayer' 

board schedule 


Follow Up Flag: Follow up 
Flag Status: Red 

I don't know yet if mouss will be calleing a schedule meeting for the 
morning (1 lam usually). If he does, I'd like to have something to say 
about schedules for the boards we have in the immediate future (ie 
main and daughter new rev's, euterpe and mnemo for pandora). Can you 
get me a first cut by 10am? 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, February 08, 1995 1:21 AM 

To: 'jeffm' 

Cc: 'billz'; 'dickson'; 'mws'; 'tbr'; 'woody'; WMail/euterpe' 
Subject: Re: Test Status - dcache_sz_16k and icachejunc 

I have a dump of dcacheharder2_V (both the _0 and _V version got to bad). 
It is on rhodan /s3. 

Lisa R. 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, February 08, 1995 9:14 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Cc: 'geert' 

Subject: Test Status 


Just an update 

BOM 218 running on Zycad - (register dependancy tests) 
BOM 223 running on IKOS 

New business 


brmisstestj) 223 - Deadlocked? dump on rhodan /s3 

dcacheharder2J) 223 - Bad - trace on rhodan /s3 6295. 1 8639 - _V dump on rhodan /s3 

dcacheharder3_0 223 - Bad - trace on rhodan /s3 7295.9430 - _V dump on rhodan /s3 

dcache_sz_4k J 223 - went to X } Traces in /n/rhodan/s3/euterpe/verilog/bsrc/res/7295 . 1 93 39 

dcache_sz_8k_l 223 - went to X } 

dcache_szj 6k_l 223 - X - trace on rhodan /s3 6295. 1 5970 

icache_runc_ 1 223 New trace in 6295 . 1 8 837 on rhodan /s3 

watchtest 223 - X - Doesn't seem to be taking a machine check, trying to get a dump 
Old Business 


dcacheannoying_V 223 - Test fix in 

dcachenoalloc_0 223 - Goes to bad dump on nosferatu /s2 - Fix released 

xlu_field_5_l 223 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/4295.29774 trying to get a dump 

icache_sz_4k_l 223 } traces in 5295.7249 Jeff these are for you! 
icache_sz_8k_l 223 } 
icache_sz_16k_l 223 } 

ex 1 1 test 2 1 8 - Dump on nosferatu /s2 

uncruptharder_0 220 - Dump on nosferatu /s2 

dcache_func_l 2 1 6 - hung dcachenoalloc NEW dump available -tbr 

ex 1 5test 223 - went to bad (expected) trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/5295 .4119 

exresgcmpritest 1 _0 } 

exresgexpitestl_0 } 
exresgm shritest 1 _0 } 

exresgrotritestl_0 } 223 - all went to bad (expected) trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/5295.41 19 

exresgshlitestl_0 } 

exresgshritestl 0 } 

exresgucmpritestl_0 } 

exresguexpitest 1 _0 } 

exresgushritestl_0 } 
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barrel! 


218 - trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/ 1295.1 1572, recreating with smaller test dramex 


exlocktest_0 
bgate^U 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 
exrleasy 214 - dump on /n/nosferatu/s2 ... problem understood 

Need sync ops: 


saaseasy 2 1 8 - Dump on nosferatu /s2 - Problem understood 

scaseasy 218 

saastest_0 

scastestO 

nb slow 223 - Running a longgggg time trace on rhodan /s3 7295. 1 9 1 05 

nbj 

nb_hermes_l 

nb_combo_l 

dcache_stress_l 

dcache__perf_ldst5t_l 

icache_stress_l 

icache_perf_5t_l 

align_at_l 

fva_conflict _1 
hermes_conflict_l 
dcache_conflict_l 
atomicconflict_l 


oc-synch_U 
synch_l 

Have not yet been run: 

doubleextestj) 
doublemctestO 

cerbstarttest_0 - Need to build a "custom" simulator 
iorupttest_0 

ruptpintest_0 - Need to build a "custom" simulator 

dcache__except_l 

align_ld_l 
align_st_l 

dcache jjerf Jd 1 t_l 
dcachejperf stlt_l 
dcache__perf Jdst 1 t_l 

addr_map_dram 

interrupt_l 

meml 

cachel 

exception_l 

bgate_l 

barrel_l 

gtlb_miss_l 
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interruptJJ 

exceptionJU 

bgate_U 

memU 

tlb_U 

synch_U 

barrel_U 

cache_U 

gtlbjnissJJ 

Cannot yet be run: 


instr_U 

instrj 

tlb_] 

insnl 

milltest 

unix 

Newly available tests 


xlurotatell 

xiu_rotate_2_I 

xlu_expandl_l 

xlu_compress_l_l 

xlu_extract_l_1 

xlu_field_l_l 

xlu_field_2_l 

xlu_field_3_l 

xlu_field_4_l 

xlucopy swap 1 _ 1 

xlu_copy swap_2_ 1 

xlu copy swap_3_ 1 

xlu_copyswap_4_ 1 

x lu_shufflemux_ 1 _ 1 

xlu_se!ect_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlongtest_0 

expriotest_0 

canceltest_0 

hermtotestO 

cerbtotestO 

hermerrtest_0 

eventregtest_0 

exintbashtestO 

cerb_registers_0 

cerberror 0 

testerinit_0 

memmapO 

nbbashtest_0 

cerbrawO 

cerbarbtests 

hcpl [tests 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 

Wednesday, February 08, 1995 11:00 AM 

•geert' 

rich_euterpe 


geert , 


i finally got thru the gplace part of 
'gmake rich_euterpegards 1 but when it got to the garoute step it didn't route anything 
???? the log file is at dickson/euterpe/verilog/bsrc/aaa . my initail route of es last ] 
ran out of disc space but it was iterating and i was hoping that it stopped in a state 
that it still could be used but i guess that could be problem, 
email me as i am still at home. 


dickson 
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From: bobm (Bob Morgan) 

Sent: Wednesday, February 08, 1 995 11:17AM 

To: 'euterpe' 

Subject: EMA v1.6 cerberus pages 

Hi, 

One of the version 1 .6 microarchitecture documents 
I distributed was missing the cerberus registers 
information. I don't know how this could have happened, 
but if anybody else's copy is also missing these pages, 
would you let me know? I'll print off those pages and 
add them to your copy for you. 
Thanks, 
Bob 
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From: vanthof (vant) 

Sent: Wednesday, February 08, 1995 11:21 AM 
To: 'sysadmin' 

Cc: Vanthof (Dave Van't Hof}'; 'hopper (Mark Hofmann)' 
Subject: missing libsuntool.so.O on mothra 

Hello, 

I tried to fire up a non-graphical version of our layout tool (compass) 
on mothra and I got this: 

ld.so: libsuntool.so.O: not found 

This program does appear to work on tomato and euterpe. Could this be 
updated on mothra? 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> 
Don't blame me, I didn't vote for him! 
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From: pmayer (Patricia Mayer) 

Sent: Wednesday, February 08, 1995 1 1:21 AM 

To: W 

Subject: Re: board schedule 

> From tbrTue Feb 7 22:35:16 1995 

> Date: Tue, 7 Feb 1995 22:35:13 -0800 

> From: tbr (Tim B. Robinson) 

> To: pmayer 

> Subject: board schedule 

> Content-Length: 314 
> 

> 

> I don't know yet if mouss will be calleing a schedule meeting for the 

> morning (1 lam usually). If he does, I'd like to have something to say 

> about schedules for the boards we have in the immediate future (ie 

> main and daughter new rev's, euterpe and mnemo for pandora). Can you 

> get me a first cut by 10am? 
> 

>Tim 

> 

I have put together a very agressive schedule, on your chair... 
Is this what your looking for? 

-Pattie 
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From: bobm (Bob Morgan) 

Sent: Wednesday, February 08 T 1 995 1 1 :30 AM 

To: 'euterpe' 

Subject: EMA v1 .6 cerberus info 

As it turns out, the cerberus pages were not missing 

from the copy I mentioned... just out of order. 

I still don't know why though, anybody else have 

this problem in their book? 

Thanks, 

Bob 
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From: doi (Derek Iverson) 

Sent: Wednesday, February 08, 1 995 1 1 :57 AM 

To: 'hardheads' 

Subject: New version of the hermes verilog model installed 

I have installed a new version of the hermes verilog model on 
the HP and Sun machines during this 10-o-clock disturbance. 
This new version has the capability to use a configuration file 
instead of using the h_config() call and a number of other 
modifications. 

Specifics can be found in /u/chip/euterpe/doc/verify.html document. 

Also, both 'startup-cycles' and 'startup^ycles' options are accepted to 
remain backward compatible. 

If you have any questions about this install, please call. 
Derek 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 08, 1995 12:25 PM 

To: 'geert* 

Subject: rich_euterpe 


geert, 

how come when i was routing iq ctioi cp cj gt and uu i was able to route when i 
"gmake rich_euterpegards" and now all i'm doing is changing the exclud lists ???? what has 
changed in the mean time ? 

dickson 
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From: graham (Graham Y. Mostyn) 

Sent: Wednesday, February 08, 1995 12:57 PM 

To: 'ras* 

Cc: 'pandora' 

Subject: Re: Pandora Transmitter 


The specific applications of the mixed signal Pandora module - besides interfacing to 
Hestia - do need clarification. 

However, it is seen as a general purpose stimulus/ test device rather than a commercial 
headend source . 

We'll discuss this in tomorrow's group meeting, and David Bulfer and I are also arranging 
a follow-on meeting with Marketing to clarify. 

The restricted dynamic range of the converters for more demanding applications has been 
raised before . 

Graham . 

> From ras Wed Feb 8 10:39:33 1995 

> From: ras (Bob Sutherland) 

> Subject: Pandora Transmitter 

> To: graham (Graham Y. Mostyn) 

> Date: Wed, 8 Feb 95 10:39:28 PST 

> Cc: pandora 

> X-Mailer: ELM [version 2.3 PL11] 

> Content -Length; 1795 
> 

> I have read the Pandora Notes and find a few errors concerning the 
section 

> on upcovnversion. 
> 

> I was asked by Graham to do the following: 
> 

> > General purpose test appli cat ion/ cable head-end/Hestia dev platform 

> > ** Bob to evaluate cost/signal quality/development time parameters 

> > for the transmit output, and the tradeoff of commercial upconverters 

> > vs. MUSE built upconverters. 

> > (This material will be used for discussion with customers next 

> > month.) 
> 

> The performance aspect of the development generated the result that we 

> could not perform (with exisitng CO) the function equivalent to the 

> performance of a commercial headend product. This prompted the e-mail 

> response in the notes. (There was no response) . 
> 

> The 17" (19" is standard, what does a 17" unit look like) upconverter 
was not 

> discussed (with me, anyway) . 
> 

> As you note from the e-mail response, we have several options. 
Depending 

> on the actual requirement (is it a headend, or just a schlock 
remodulator 

> translated to an arbitrary TV channel) we must do different things. 

> My understanding is that it's a headend performance unit. This then 
prompted 

> the following response to an e-mail (on muse .pandora) about a schlock 

> remodulator option: 
> 

> >What the hell is this ! ! 1 

> > 

> >There is nothing in the Pandora Technical specification that covers 

> >the 
transmitter 

> >section performance for anything othe than channel 3/4 modulator or 
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uplink. 

> > 

> >If we are required to support this, I recommend that the cognizant 
people be included 

> >in the discussion. We still have no closure on what the performance 
criteria is for 

> >the signal sample. Is it headend quality, or channel 3/4 remodulator 
quality? 

> 

> The question still remains., what exactly are we building? 


> "No! No!.. Don't pull on that.. you never know what it's attached to." 
> 

> RAS 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 08, 1995 4:14 PM 

To: 'geert' 

Subject: rich_euterpe 


geert, 


it appears that the fix to Makefile. tst did something good, i can see that the route 
is proceeding as expected, 
thanks for easing my frustration : ) 

dickson 
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From: tbr 

Sent: Wednesday, February 08, 1995 5:28 PM 

To: 'yves (Jean-Yves Michel)' 

Cc: 'noel'; 'pandora'; Vijay@MicroUnity.com' 

Subject: Re: Linear power supplies 


Follow Up Flag: Follow up 
Flag Status: Red 


Jean -Yves Michel wrote (on Wed Feb 8): 

Vijay wrote on Tue Feb 7: 

> 

> I saw you rnote to Pandora regarding Power dissipation. I need your help 

> in clarifying your note so that I can write a power supply spec. 

> 

> 

> I am trying to spec the outout of the Linears at -9V @ ? amps, 28V @ ?amps. 


Vijay, the mail you are referring to, was not intended to spec the linear 
supplies of pandora. I was answering to Tom's request for the thermal analysis 
of one possible Calliope brick. 

In the future we may have more designs according to customer requests (ISDN 
interface for instance). Also the CMOS Euterpe brick will probably use the 
28 and -9V. 


Here are my best guesses for non-3 .3 V supply needs: 

24V 12V 5 V -5V 

* cable calliope module: 0.3 2.7 0.8 0.3 

* isdn calliope module: 0.2 0.7 0. 1 

* cmos euterpe module : 0.7 0.3 

* unforseen needs: 0.2 0.5 1.0 0.2 

TOTAL used : 0.5 3.4 3.2 0.9 
local regulator losses: 0.1 1.0 0.7 0.7 


Needed 28V supply power 8.9 W 

Needed -9V supply power 1 .6 W 


Assuming that: * we generate locally (inside modules, when needed) 24V and -5V 
with linear regulators (4V drop-out) 

* we generate +12 and +5V using local high efficiency DC-DC 
regulators (>80%) followed (or not) by linear regulators 


So I suggest we design the 28V supply for about 10W or 360mA and the -9 V 
supply for 2W or 220mA. 

If anybody disagree or has different guesses or wants more margin, please 
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let me know. 

This seems to overlook the fact that the CMOS Euterpe will be 5V for 
it's main power (>100W). 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Wednesday, February 08, 1995 5:30 PM 

'geert' 

'dbulfer 1 

CMOS euterpe power 


Follow Up Flag: Follow up 
Flag Status: Red 

How are the Hermes outputs on the CMOS euterpe going to be referenced 
to the power rails? I'm worried that if we reference them to the 
upper rail we will need split supplies of 3V and -2V to make them 
compatible with the bipolar Mnemosyne. 

A similar (but perhaps easier to manage problem) may arize with the 
Cerberus output. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, February 08, 1 995 5:30 PM 

To: 'geert' 

Cc: 'dbulfer' 

Subject: CMOS euterpe power 


How are the Hermes outputs on the CMOS euterpe going to be referenced to the power rails? 
I'm worried that if we reference them to the upper rail we will need split supplies of 3V 
and -2V to make them compatible with the bipolar Mnemosyne. 

A similar {but perhaps easier to manage problem) may arize with the Cerberus output. 
Tim 


Exhibit Cll 


Page 151 of 5 


From: geert {Geert Rossee!) 

Sent: Wednesday, February 08, 1995 5:46 PM 

To: W 

Cc: 'dbulfer' 

Subject: Re: CMOS euterpe power 

Well you make a very good point and I don't know the answer 
to that one yet. Do we have 3 V easily available on the 
Cronus module ? Can we bring in the 3 V supply just for 
the Hermes channel I/O ? 

Geert 
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From: two (Fred Obermeier) 

Sent: Wednesday, February 08, 1995 6:19 PM 

To: 'hardheads' 

Subject: Csyn Euterpe BOM 223 errors 


Hi, 

Csyn now performs more stringent checks on wired emitter (w) and wired collector (y) 
nodes. If one uses a #w or #y, then the # must match among all the driver nodes. If one 
uses numberless w or y, then all drivers must use the same numberless w and/or y. 
More restrictive checks will follow. 


The Output Short check errors found in tbr_euterpe-passl . spivs generated from bsrc BOM 
223.0 are listed below. Please let me know when these errors have been fixed. 


Thanks , 
Fred. 


excerpts from 

/u/ f wo/chip .bsrc/euterpe/verilog/bsrc/SAVE . 223/pelagon/* . csyn 
Lines beginning with # are my comments : 


error (OutputShortCheck. 13 09) in file " tbr_euterpe -pas si . spivs" : 
drivers must have same num of collectors 


topmost net : 

instance path: top . xgtlb . x2p_l . tail_vw_l 
cellname path: top.gtlb . tlbxrablk. tail_vw_l 
drivers : 

instance path: tlbxrablk . x2p__l . tail_vw_l 

cellname path: tlbxrablk. tlbvtailO . tail_vwy_l 

instance path: tlbxrablk.xlp_l .xlp_l .xlxlp_l \ 

.xl2p__l .x4p_l .tail_vw 

cellname path: tlbxrablk . tlbxr74col . tlbxrScolsO . tlbxr8col\ 

. tlbrwliselsO . tlbrwlisel . tail_vw 
. . . many tlbxr74col lines delete . . . 

# Remove the 'y' from tail_vwy_l since many more tlbxr74col # cells don't use the 'y' . 

warning (AnalyzeWiredLea f Nodes . 483 > in file " tbr_euterpe-passl . spivs" : 
leaf nodes have inconsistent wire designations 

Connect list, cnlst, seeded from node tail_vwy_l 

outputs: WiredEmitters? WiredCollectors? 

tlbrwlisel . rwl_an2p42 7 v TRUE TRUE 

tlbrwlisel . tail_vw TRUE TRUE 

. . . many tail_vw deleted . . . 

t lbvt ai 1 0 . t ai l_vwy_l TRUE TRUE 

# Change rwl_an2p427v to rwl_an2p4 2 7vw 

# Change tail_vwy_l to tail_vw _1 

error (OutputShortCheck. 13 02) in file "tbr_euterpe-passl . spivs" : 
drivers must have same num. of emitters 


topmost net: 

instance path: top . xgtlb. x2p_l .xlp_l .xlp_l \ 

,xlxlp_l .rwl_an2p427vwy_10 
cellname path: top.gtlb . tlbxrablk . tlbxr74col . tlbxr8cols0 \ 

. t lbxr 8 co 1 . r wl_an2p4 2 7 vwy_l 0 
drivers : 

instance path: tlbxrScol .xl2p_l .xl0x4p_l . rwl_an2p42 7v_10 

cellname path: tlbxrScol . tlbrwliselsO . tlbrwlisel . rwl_an2p42 7v 
# Change or fix both rwl_an2p427v to rwl_an2p427vw 
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warning (Analy zeWiredLeaf Nodes . 483 ) in file "tbr_euterpe-passl . spivs" : 
leaf nodes have inconsistent wire designations 

Connect list, cnlst, seeded from node tail_vwy_l 


outputs: WiredEmitters? 
tlbrwlisel . rwl_an2p427v TRUE 
tlbrwlisel.rwl_an2p427v TRUE 
tlbrwlisel . tailjvw true 
. . . many tail_vw deleted . . . 
tlbvtailO . tail_vwy_l TRUE 


WiredCol lectors? 
TRUE 
TRUE 
TRUE 

TRUE 


top . xgt lb . x2p_l 


. xlp_l 


.xlp_l 


. xlxlp_l 


topmost net : 

instance path: 
. rwl_an2p427vwy_ll 

cellname path: top.gtlb 
. tlbxrablk. tlbxr74col . tlbxr8cols0 . tlbxr8col . rwl_an2p427vwy_ll 
drivers : 

instance path: tlbxrScol .xl2p_l .xllx4p_l . rwl_an2p42 7v_ll 

cellname path: tlbxr8col . tlbrwliselsO . tlbrwlisel . rwl_an2p427v 

warning ( Analy zeWiredLeaf Nodes . 483 ) in file " tbr_euterpe-passl . spivs" : 
leaf nodes have inconsistent wire designations 

Connect list, cnlst, seeded from node tail_vwy_l 


outputs: WiredEmitters? 
tlbrwlisel . rwl_an2p4 2 7v TRUE 
tlbrwlisel . rwl_an2p4 2 7v TRUE 
tlbrwlisel . rwl_an2p4 2 7v TRUE 
tlbrwlisel . tail_vw TRUE 
. . . many tail_vw deleted . . . 
tlbvtailO . tail_vwy_l TRUE 


WiredCollectors? 
TRUE 
TRUE 
TRUE 
TRUE 

TRUE 


.xlxlp_l 


topmost net: 

instance path: top . xgt lb . x2p_l .xlp_l .xlp_l 
. rwl an2p42 7vwy_12 

cellname path: top.gtlb 
. tlbxrablk. tlbxr74col . tlbxr8cols0 . tlbxr8col . rwl_an2p4 2 7vwy_12 
drivers : 

instance path: tlbxr8col . xl2p_l .xl2x4p_l . rwl_an2p42 7v_12 

cellname path: tlbxr8col . tlbrwliselsO . tlbrwlisel . rwl_an2p427v 


same true for rwl_an2p427vwy_0 through rwlan2p427vwy_63 
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Subject: 


Sent; 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, February 08, 1995 6:25 PM 
'guarino'; 'gmo'; 'jeffm'; 'sandeep'; 'wayne'; 'gregg' 
'hestia' 

Software Bringup Meeting Minutes - February 8, 1995 


Software Bringup Meeting 


February 8, 1995 


Next Meeting: 


February 15 at 10:00 am. 


Attendees: jeffm, guarino, gregg, doi, sandeep 


New Action Items 


Item: Specify and Design ISA/Cerberus Card 
Who: gmo and others? 
Status: New 


Item: Refine remote debugging environment 
Who : sandeep 
Status : New 


We have to decide how control (and state) is to be returned 
to the debug stub after a test runs . 


Review of Action items 


Item: IKOS support for "fake calliope" 
Who: jeffm 
Status : Pending . 

In order to run our realtime benchmark test, we need some way 
to get data in and out of the HW simulator at the speed 
of a Calliope access. We would also like some way to cause 
fake calliope events to be posted at regular intervals. 

A number of possibilities were discussed during the meeting: 

o add a fake calliope to the verilog/zycad hermes model, 
o connect to a "real 1 calliope on the hw simulator 
o possibly fake out events by having a timer on euterpe 
simulating the events that a calliope would generate. 

Since the meeting I have talked with Lisa R. about some of these 
solutions. It was calculated that the earliest that we" would have 
IKOS cycles to run such a test would be about the middle of March 
and this would be about the time frame that we could have a 
calliope running on the IKOS too. This seemed like the best 
decision. 

Item: Status of Euterpe/Mnemo simulation 
Who: jeffm, gmo 
Status: Pending. 

Jeffm figured that in 2 - 3 weeks time there would be a need 
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for terp/mnemo capability to support the verification effort . 
An issue was raised that this may not be enought time for the 
required additions to terp to be made. 

Item: Test interleaved access 
Who : guar i no 
Status: Pending. 

Loretta started to look at this but requires terp support. 
Terp changes are on hold until the real-time benchmark is 
is running again. 

Item: Create a microkernel that doesn't access calliope 
Who : sandeep 

Status: In progress. Expected completion 2/15 


Item: Build microkernel tests for IKOS 
Who: sandeep, doi 

Status: In progress. Expected completion 2/15 

Create images for boot test, snapshot images for microkernel 
tests . 

Item: DVT boot 

Who: sandeep 

Status : In progress . 

First step is to get nano-boot running on the HW simulator. 

Item: Unsnap code 
Who: sandeep, guarino 
Status : Pending . 

This is expected to be started 2/15. 

Item: Run real-time test (mpeg benchmark) on the HW simulator. 
Who : gregg 

Status: In progress. 

There are problems getting the benchmark to run on the 
software simulator. Work continues to find out where 
the problems are. The compilers, simulator, kernel, and 
benchmark areas are "frozen* (in terms of checking in 
new changes) until the problem has been identified. 


Item: Build scripting/UI capabilities above gdb for regression tests. 
Who: doi 

Status: On hold until the the boot, gdb boot stub, and virtual devices 

are complete. 


Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/3 0] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware. 

Completed Items 


Item: More investigation on CBI and workstation interface issues. 
Who : guarino , wayne 
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Status : Done . 


It was decided that there will be a development effort 
to create a ISA card that talks cerberus . A new item 
has been created to track this new task. 


Item: Implement parallel port device driver for Linux on PC. 
Who: jerry, doi 
Status: Cancelled. 

We are no longer looking at a parallel/Cerberus interface 
solution. 


Item: Rerun dcacheharder and icacheharder tests and get cycle count 
results . 
Who : doi 

Status: [01/11] Done. 

Lisar ran the tests and has the cycle counts. 


Item: Define and implement a snapshot environment for the HW and SW 

simulators. 
Who: jeffm, gmo, guarino 
Status: [11/30] Done. 

This has been defined and a second item has been 
created to track the individual items to be worked on. 


Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who : sandeep/gmo 
Status: Done. 

This basic task has been complete. New items have been created 
to track modi ficat ions /enhancement s . 


Item: Simulator needs to understand "reset 1 
Who : gmo 

Status: [11/3 0] Done (but waiting for the "defrosting' of the sw 

environment . 


Test Status 


Jeff talked about test and debug status. 


Software Simulator Status (left over from the 2/1 Meeting) 


Requests for additional terp functionality: 

Reset (in test) 

X (uninitialized) values 

checkpoint /snapshot 

Hermes devices at all Hermes addresses 

Observe functionality of Cerberus bits (e.g. Hermes 

c hanne 1 enab 1 e ) 
Wrapping spaces (especially DRAM) 
"fake calliope" support 

holes in the address space, unimplemented Hermes channels 
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Subject: 


From: 
Sent: 
To: 
Cc: 


vanthof (vant) 

Wednesday, February 08, 1995 6:28 PM 
'paulp (Paul Poenisch)' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'torn (Thomas Laidig)'; 'geert (Geert 
Rosseel)'; 'bpw (B. P. Wong)'; 'efelias (Eldred Felias)' 
n+ Implant errors in gtlb 


Paul, 


The fullchip lower drc 1 s came back today and there are about 45000 N+ Implant drc 
violations in the gtlb section. By doing a grow/ shrink of 4.5, the min spacing violations 
would go away in this case. Last week there was some effort into cleaning these up, what 
was the outcome? 

These are the only drc errors left in euterpe lower layers and the metals are almost 
clean as well. I'd like to come to a resolution on this quickly to get the database in a 
stable state. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

25 5 Caspian Way, Sunnyvale, CA (408) 7 34-8100 X27 6 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him] 


Thanks, 


Dave 
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Subject: 


Sent: 

To: 

Cc: 


From: 


dbulfer (David Bulfer) 

Wednesday, February 08, 1995 6:28 PM 

Tim B. Robinson' 

'yves (Jean-Yves Michel)'; 'noel (Noel Verbiest)'; 'pandora'; 'vijay@MicroUnity.com' 
Re: Linear power supplies 


tbr writes: 
> 

> This seems to overlook the fact that the CMOS Euterpe will be 5V for 

> it's main power (>100W) . 


This is all in reference to the ultra low noise power requirements of the Calliope module. 
I think that we have 5V covered, I do, though, think it is important to nail down the 
foundary for the CMOS Euterpe. 
It would be a shame to run it at 5V. 


David 
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From: dbuifer (David Buffer) 

Sent: Wednesday, February 08, 1995 6:32 PM 

To: 'Jean-Yves Michel* 

Cc: 'tbr (Tim B. Robinson)'; 'pandora' 

Subject: Re: Linear power supplies 

> 

> Ooops! I thought CMOS Euterpe will also be 3.3V. 

Last I heard, we don't have a foundary. I don't think that we know if 
it is 5V or 3.3. 

> 

> Anyway, the analog circuits will definitely not share anything with this 5V. 

> Also for power efficiency, would not it be much better to have a special power 

> supply for this 5V with a DC-DC converter directly from 300V rather than 

> going in 2 steps: 300 to 28 and 28 to 5? 

> 

We are not using a 300V PS for Pandora. All voltages are directly 
generated from the AC line. 

David 
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From: dbulfer (David Bulfer) 

Sent: Wednesday, February 08, 1995 6:39 PM 

To: 'Geert Rosseel' 

Cc: 'tbr (Tim B. Robinson)' 

Subject: Re: CMOS euterpe power 


> Well you make a very good point and I don ' t know the answer to that 

> one yet . Do we have 3 V easily available on the Cronus module ? Can we 

> bring in the 3V supply just for the Hermes channel I/O ? 
> 

> Geert 
> 

We will make what ever voltages necessary available. 3V is certainly available. The 
question is "Do we need 5V in that slot also?" 

Correct me if I am wrong, but it is my understanding is that we are still looking for a 
CMOS foundary since our friends seem to be a dubious source. 

David 
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From: vanthof (vant) 

Sent: Wednesday, February 08, 1995 7:02 PM 

To: 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'vo (Tom Vo)'; 'hopper 

(Mark Hofmann)' 
Cc: 'vanthof (Dave Van't Hof)' 

Subject: short in euterpe 


There is a power/ground short in euterpe. When I get home, I'll start up the quadrant 
short checks again. 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ftinclude <std_disclaim. h> Don't blame 
me, I didn't vote for him! 
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From: 
Sent: 


tbr 


To: 


Cc: 


Subject: 


Wednesday, February 08, 1995 7:03 PM 
'lisar (Lisa Robinson)' 
'bobm'; 'craig'; 'dickson'; 'euterpe'; 'jeffm' 
double machine check bit 


Follow Up Flag: Follow up 
Flag Status: Red 

Lisa Robinson wrote (on Tue Feb 7): 


According to the TSA and the Euterpe MicroArchitecture document 
bit 60 of oclet 7 is the double machine check bit. 

Calliope and the current implementation of Euterpe use this bit to 
indicate low voltage or temperature. 

What is bit 59 in Euterpe oclet 7 intended to be used for (current documentation 
says this bit is reserved for indicating additional causes of reset) and could it 
be used for double machine check. 

OK. Let's move double machine check to bit 59 and retain bit 60 as 
the status of the bg3stack. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, February 08, 1995 7:03 PM 

'lisar (Lisa Robinson)' 

'bobm'i 'craig'; 'dickson'; 'euterpe'; 'jeffm' 

double machine check bit 


Lisa Robinson wrote (on Tue Feb 7) : 


According to the TSA and the Euterpe MicroArchitecture document 
bit 60 of oclet 7 is the double machine check bit. 

Calliope and the current implementation of Euterpe use this bit to 
indicate low voltage or temperature. 

What is bit 59 in Euterpe oclet 7 intended to be used for (current documentation 
says this bit is reserved for indicating additional causes of reset) and could it 
be used for double machine check. 

OK. Let's move double machine check to bit 59 and retain bit 60 as the status of the 


bg3 stack. 


Tim 


Exhibit Cll 


Page 165 of 5 


From: tbr 

Sent: Wednesday, February 08, 1995 7:25 PM 

To: 'dbulfer (David Buffer)' 

Cc: 'Geert Rosseel' 

Subject: Re: CMOS euterpe power 

Follow Up Flag: Follow up 

Flag Status: Red 


David Bulfer wrote (on Wed Feb 8): 


> Well you make a very good point and I don't know the answer 

> to that one yet. Do we have 3 V easily available on the 

> Cronus module ? Can we bring in the 3 V supply just for 

> the Hermes channel I/O ? 

> 

> Geert 

> 

We will make what ever voltages necessary available. 3V is certainly 
available. The question is "Do we need 5V in that slot also?" 

Correct me if I am wrong, but it is my understanding is that we are 
still looking for a CMOS foundary since our friends seem to be a 
dubious source. 

Our friends are no source at all. Mouss wants something truly 
portable and as I understand the current plan we are back to CSM. 

I think we have to assume we have 1 50 W of 5 V available as an 
alternative to the 85 W of 3.3V but that we will still want the 3.3V 
available to power the output drivers. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gaea.microunity.com] 

Wednesday, February 08, 1995 7:25 PM 

'David Bulfer' 

'Geert Rosseel' 

Re: CMOS euterpe power 


David Bulfer wrote (on Wed Feb 8) : 


> Well you make a very good point and I don't know the answer 

> to that one yet. Do we have 3 V easily available on the 

> Cronus module ? Can we bring in the 3V supply just for 

> the Hermes channel I/O ? 
> 

> Geert 
> 

We will make what ever voltages necessary available. 3V is certainly 
available. The question is "Do we need 5V in that slot also?" 

Correct me if I am wrong, but it is my understanding is that we are 
still looking for a CMOS foundary since our friends seem to be a 
dubious source . 

Our friends are no source at all. Mouss wants something truly portable and as I 
understand the current plan we are back to CSM. 

I think we have to assume we have 150W of 5V available as an alternative to the 85W of 
3.3V but that we will still want the 3.3V available to power the output drivers. 


Tim 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 08, 1995 8:29 PM 

To: 'geert' 

Subject: rich_euterpe 


geert, 

it did in fact work with this mornings Makefile. tst 
there are some conjestion points which i am attempting to solve, 
thanks dickson 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 08, 1995 8:35 PM 

To: 'tbr' 

Subject: euterpe cerberus reg 07 
tim, 

this is how it is currently wired. 

bit 63 terpreset_anm 
bit 62 terpreset_anm 
bit 61 meltdn_abm 
bit 60 sok_ab0pm 
bit 59 ddmchk_am 
bit 58 exevthrd am 
bit 57 wdogto am 
bit 56 cerbxerabm 
bit 55 SCRCErr_abm 
bit 54 SCmdErr_abm 
bit 53 hcto_am 

i dont remember why bit 63 and 62 are the same ??? 
dickson 
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From: 
Sent: 
To: 

Subject: 


fwo (Fred Obermeier) 
Wednesday, February 08, 1995 8:54 PM 
'brianl'; 'fwo'; 'geert'; 'torn'; 'wingard' 
incorrect phi_a/phi_b net hookups. 


Hi, 


To quell possible fears over a csyn loophole, I've confirmed that there isn't a bug in 
csyn's checking of phi nets. 

As Drew suggested, I've added a test case to the csyn rules file, and csyn does indeed 
catch this wiring error on a smaller example. 

So the differential input swing check is correctly identifying this error. 

I haven't gotten csyn to run to completion on euterpe since I made changes to ignore top- 
level interface pins on differential inputs. 

I've been fixing csyn core-dump errors I've recently introduced while trying to speed up 
the phi checking for the differential input swing checks that only euterpe seems to 
tickle. Once I get this code working on euterpe, I'll make sure the error list I sent 
Geert is also produced by these netlists. 

You'll notice that the last Euterpe Csyn e-mail I sent out didn't say anything about 
Differential Input Swing checks. I'm keeping around the older versions of the spivs decks 
to check this once I get csyn working faster again. 


Fred. 
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From: tbr 

Sent: Wednesday, February 08, 1995 10:05 PM 

To: 'dickson (Richard Dickson)' 

Subject: euterpe cerberus reg 07 

Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Wed Feb 8): 
tim, 

this is how it is currently wired. 

bit 63 terpresetanm 
bit 62 terpreset anm 
bit 61 meltdn_abm 
bit 60 sok_abOpm 
bit 59 ddmchkam 
bit 58 exevthrdam 
bit 57 wdogtoam 
bit 56 cerbxerabm 
bit 55 SCRCErr_abm 
bit 54 SCmdErr_abm 
bit 53 hcto_am 

i dont remember why bit 63 and 62 are the same ??? 

They aren't defined to eTb the same. Bit 63 means "reset or self test 
complete". Bit 62 means "reset or self test successful". Since we 
originally had no self test only reset was relevant, and that could 
not fail, so we just wired both bits to the inverse of the 
reset bit, so they were bot cleared during reset, and set at the end. 

I think this is still what we want for Euterpe, but in mnemo we will 
have built in self test, so bits 63 and 62 will have different sources 
depending on whether self test is enabled or not. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Wednesday, February 08, 1995 10:35 PM 
"solo (John Campbell) 

'vanthof (Dave Van't Hot)'; 'hopper (Mark Hofmann)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa 
Robinson)'; Vo (Tom Vo)'; 'geert (Geert Rosseel)' 
chache has the power/ground short 


John, 


I finally checked into why the cache lvs was running so long. There is a power/ground 
short in it. The lvs job is currently in LVSCHM (the compare 

stage) and is completely bogus. I'm going to kill this run and manually restart it after 
this particular stage so as to get the shorting polygons. 
This will help in tracking down the euterpe short. 

Hope this is okay. 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim. h> Don't blame 
me, I didn't vote for him! 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, February 08, 1995 1 1:30 PM 

To: 'dickson' 

Cc: 'jeffm'; 'tbr' 

Subject: watchtest or cerbraw 

Rich 

Rich I think that these tests are failing because x's are propagating 
after a read of octlet 7 from the rawdata field. 

In the dump /n/nosferatu/s2/euterpe/verilog/cerbraw_0.dump 
the signal Csampleabm becauses true after the signal rdring07_bm 
doesn't this mean that the rawdata is missed and the X's that were in the 
latch propagated? 

Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Thursday, February 09, 1995 2:45 AM 

'Geert Rosseel' 

'tbr (Tim B. Robinson)'; 'torn (Thomas Laidig)'; 'vo (Tom Vo)' 
Re: GARDS problem 


Geert Rosseel writes: 

I've run into a problem with GAROUT. It dies after a couple of 
hours in line-search. It's not giving any indications why. I've 
run it twice and it dies in exactly the same spot (about 38% complete) . 

I believe it has something to do with the RLOAD step . I need to do 
the RLOAD step for getting the XLU wires . I ran the route before 
without the RLOAD step and it completed. After I added the RLOAD step, 
it died twice . The RLOAD step did finish properly as far as I can see. 

I need help . . . 


All the data is in /n/ghidra/s3/geert/euterpe/verilog/bsrc 
makefile outputs are : rload.out and route. out 

Could this be one of those limits problems that Kurt had worked around by substituting 
another release version of the Gards code? 


Geert 


-hopper 
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From: vanthof (vant) 

Sent: Thursday, February 09, 1995 8:21 AM 

To: 'solo (John Campbell)' 

Cc: Vanthof (Dave Van't Hof)\ 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)' 

Subject: cache short appears to be gone now 


I believe I've fixed the short in the cache. The shorts run came back clean. 

I'm still going to let the shorts checks for euterpe continue today, then I'll start up 

another fullchip run. 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim. h> Don't blame 
me, I didn't vote for him! 
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From: geert (Geert Rosseel) 

Sent: Thursday, February 09, 1995 8:58 AM 

To: 'tbr'; 'torn'; Vo' 

Cc: 'hopper' 

Subject: GARDS problem 

I've run into a problem with GAROUT. It dies after a couple of 
hours in line-search. It's not giving any indications why. I've 
run it twice and it dies in exactly the same spot (about 38% complete). 

I believe it has something to do with the RLOAD step. I need to do 
the RLOAD step for getting the XLU wires. I ran the route before 
without the RLOAD step and it completed. After I added the RLOAD step, 
it died twice . The RLOAD step did finish properly as far as I can see. 

I need help ... 

Geert 

All the data is in /n/ghidra/s3/geert/euterpe/verilog/bsrc 
makefile outputs are : rload.out and route.out 
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From: 
Sent: 
To: 
Cc: 

Subject: 


solo (John Campbell) 

Thursday, February 09, 1995 9:20 AM 

'vant' 

Vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa 
Robinson)'; 'vo (Tom Vo)'; 'geert (Geert Rosseel)' 
Re: chache has the power/ground short 


as vant was saying 


. .John, 

I finally checked into why the cache lvs was running so long. There 

is 

, .a power/ground short in it. The lvs job is currently in LVSCHM (the compare 
..stage) and is completely bogus. I'm going to kill this run and manually ..restart 
after this particular stage so as to get the shorting polygons. 
..This will help in tracking down the euterpe short. 


it 


. .Hope this is okay. 
. .Dave 


sounds like another great plan 


regards , 

solo a.k.a. John Campbell x516 
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From: solo (John Campbell) 

Sent: Thursday, February 09, 1995 10:13 AM 

To: 'Mark Hofmann' 

Cc: Vanthof@MicroUnity.com'; Vanthof (Dave Van't Hot)'; 'geert (Geert Rosseel)' 

Subject: Re: short in cache found 


as Mark Hofmann was saying 

. . [And it shows we really need to follow our rules about LVSing the pieces . .before we try 
to LVS the whole . ] 
. . -hopper 


my log shows that the last time the make fired it off in /u/chip was 
1/23 and it completed on 1/24 with no shorts or errors. 

As late as february 4, the last time it could have run, it didn't so when was the fatal 
change made. 

presumably one of the following is the culpret . 

cellname cvsrev 
cvsdate 

/u/chip/euterpe/proteus/compass/layouts/cabicx4 . ly 6.10 
Feb 3 16:50:11 1995 

/u/ chip/euterpe/proteus /compass/ layouts /cabotwaff . ly 6.9 
Feb 7 08:36:53 1995 

/u/chip/euterpe/proteus/compass/layouts/cabsor5 . ly 6.3 
Feb 3 16:37:38 1995 

/u/chip/euterpe/proteus/compass/layouts/cabsordmy. ly 6.3 
Feb 7 08:36:57 1995 

/u/chip/euterpe/proteus/compass/layouts/cacasldl2 . ly 5 . 17 

Feb 3 16:37:46 1995 

/u/chip/euterpe/proteus/compass/layouts/cacornerpwrx . ly 8.4 
Feb 3 16:37:50 1995 

/u/chip/euterpe/proteus/compass/layouts/caf sam4 . ly 6.4 

Feb 3 16:37:54 1995 

/u/chip/euterpe/proteus/compass/layouts/caf sam4wr . ly 8 .2 

Feb 3 16:37:58 1995 

/u/chip/euterpe/proteus/compass/layouts/caf sam4wr8 . ly 8.2 
Feb 3 16:38:02 1995 

/u/chip/euterpe/proteus/compass/layouts/caf sam4wr8a . ly 8.2 
Feb 3 16:38:36 1995 

/u/chip/euterpe/proteus/compass/layouts/caf samx . ly 6.7 
Feb 3 16:21:22 1995 

/u/ chip/euterpe/proteus /compass/ layout s/cagsa . ly 5.7 
Feb 3 16:50:15 1995 

/u/chip/euterpe/proteus/compass/layouts/calocsa . ly 5.15 
Feb 6 07:53:16 1995 

/u/chip/euterpe/proteus/compass/layouts/camcellcapl . ly 4.8 
Feb 6 07:53:22 1995 

/u/chip/euterpe/proteus/compass/layouts/camcellcap2 . ly 5.7 
Feb 3 16:21:26 1995 

/u/chip/euterpe/proteus/compass/layouts/camcellcap3 . ly 8.4 

Feb 3 16:21:30 1995 

/u/chip/euterpe/proteus/compass/layouts/camcellcaplf t . ly 5.6 
Feb 3 16:22:08 1995 

/u/ chip/euterpe/proteus/ compass /layouts /caorlwp . ly 6.6 
Feb 3 16:22:21 1995 

/u/ chip/euterpe/proteus/ compass/ layout s/caor2cas . ly 5 . 13 

Feb 3 16:22:26 1995 

/u/chip/euterpe/proteus/ compass /layout s/caor2wp. ly 6 .7 

Feb 3 16:50:25 1995 

/u/chip/euterpe/proteus/compass/layouts/caor2wpdmy . ly 6 . 6 
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Feb 3 16:22:32 1995 

/u/chip/euterpe/proteus/compass/layouts/caor3cas . ly 5 . 11 

Feb 3 16:22:39 1995 

/u/chip/euterpe/proteus/compass/layouts/ caor3wp . ly 6.6 
Feb 6 07:53:36 1995 

/u/chip/euterpe/proteus/compass/layouts/capld. ly 5 . 3 

Feb 3 16:50:29 1995 

/u/chip/euterpe/proteus/compass/layouts/ cardbs . ly 5 . 14 

Feb 3 16:22:45 1995 

/u/chip/euterpe/proteus/compass/layouts/carddec . ly 5.22 
Feb 7 08:37:07 1995 

/u/chip/euterpe/proteus/ compass /layouts/ cardf_abin. ly 5 . 7 

Feb 3 16:23:02 1995 

/u/chip/euterpe/proteus/compass/layouts/cardfdec8 . ly 5.18 
Feb 3 16:23:43 1995 

/u/chip/euterpe/proteus/compass/layouts/cardf dec_cmos . ly 5.11 
Feb 3 16:23:48 1995 

/u/chip/euterpe/proteus/compass/layouts/cardf decorout . ly 5.5 
Feb 3 16:23:54 1995 

/u/chip/euterpe/proteus/compass/layouts/cardiref . ly 8.4 
Feb 6 07:53:42 1995 

/u/chip/euterpe/proteus/compass/layouts/carsbuf . ly 6.3 

Feb 3 16:24:00 1995 

/u/chip/euterpe/proteus/compass/layouts/catopwaf f . ly 6 . 12 

Feb 3 16:24:06 1995 

/u/chip/euterpe/proteus/compass/layouts/cavref 942 . ly 6.6 
Feb 3 16:24:42 1995 

/u/chip/euterpe/proteus/compass/layouts/cavwyisrc . ly 5 . 13 

Feb 7 08:37:12 1995 

/u/chip/euterpe/proteus /compass/ layouts/cawrdec2 . ly 6.6 
Feb 3 16:50:34 1995 

/u/chip/euterpe/proteus/compass/layouts/cawrpre4a . ly 6.5 
Feb 3 16:24:57 1995 

/u/chip/euterpe/proteus/compass/layouts/cawrpre8xb . ly 6 . 11 

Feb 7 08:37:16 1995 

/u/chip/euterpe/proteus/compass/layouts/caxdrv. ly 6.9 
Feb 3 16:50:38 1995 

/u/ chip /euterpe /pro teus /compass/ layout s/ caxdrvdmy . ly 6 . 5 

Feb 3 16:25:11 1995 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-813 6 
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From: wampler (Kurt Warn pier) 

Sent: Thursday, February 09, 1995 1 1 :07 AM 

To: 'geerf 

Subject: Re: New top-level Euterpe 


> Hi Kurt, 


> I've got a new top-level Euterpe . The main difference with the 
>previous one is that I swapped sr and at placement. Can you route this please 
> 

> Geert 


Hi, 


I talked to hopper last night and he said you were able to proceed with 
routing in my absence. I'm sort of grounded here at home by the doctor 
until Monday; I'll try to keep up with e-mail, but I'm not ready to 
resume full activity yet. 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


jeffm (Jeff Marr) 

Thursday, February 09, 1995 12:45 PM 
'euterpe 1 

dtag/itag addressing 


There has been a major misunderstanding about tag addressing. 

To access the tags, the tag address offset is in address bits 13:6. The address of the 
second dtag entry is not 0x800000a00008 , it is 0x800000a00040 . Bits 5 : 0 of the address are 
ignored. 

This would mean that the tags repeat every 16K. 
Comments? 


jeffm 
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From: jeffm {Jeff Marr) 

Sent: Thursday, February 09, 1995 1:32 PM 

To: 'tbr (Tim B. Robinson)' 

Subject: Test Status - dcacheharder2 

Tim B, Robinson writes: 

> 

> Jeff Marr wrote (on Thu Feb 9): 

> 

> One of the problems highlighted by this test is that 

> there has been a major misunderstanding about how the tags 

> are to be read and written. Whether this is intentional 

> or not, here is how I think it works (mws - you were correct): 

> 

> To directly read and write the tags, the tag address offset is 

> in bits 13:6. The address of the second dtag entry is not 

> 0x800000a00008, it is 0x800000a00040. Bits 5:0 of the 

> address are ignored. 

> 

> This would mean that the tags repeat every 16K? I am not sure 

> whether that means that any HW is going to prevent us from 

> accessing higher tag addresses, or whether the documentation 

> is wrong. 

> 

> Comments? 

> 

> We already thought the documentation is wrong, but the only thing that 

> seems to make sense to me is to have them repeat every 2K (ie the size 

> of the tag) or we have to define what happens in the holes. 

> 

>Tim 

> 

This is a completely different question than the wrap size. The issue 
here is how the tags are addressed - terp and all the SW assume that 
bits 10:3 of the address are used to access the tags, but bits 
13:6 are used. Bits 5:0 are ignored. 

jeffm 
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From: hopper (Mark Hofmann) 

Sent: Thursday, February 09, 1995 1:41 PM 

To: Vanf 

Cc: 'ericm (Eric Murray)'; 'vanf; 'tbr (Tim B. Robinson)' 
Subject: Re: crack-pwc on trex 

vant writes: 
Hi Eric, 

I'm starting up fullchip drc runs and I'd like to use trex. Could you 
turn the priority down on your stuff? I will be using all 4 processors 
on that machine. 

Thanks, 
Dave 

I see that crack-pwc is still running. 

I have paged Eric, asking him to kill this job so that we can use trex 
for tapeout. 

-hopper 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Lisa Repka [lisa@calliope] 
Thursday, February 09, 1995 2:13 PM 
'Jeff Marr' 

'euterpe@calliope'; 'lisa@calliope' 
Re: dtag/itag addressing 


In article <199502091845 . KAA2275 8@mercury . microunity . com> , you write: 

> There has been a major misunderstanding about tag addressing. 
> 

> To access the tags, the tag address offset is in address bits 13:6. 

> The address of the second dtag entry is not 0x800000a00008 , it is 

> 0x800000a00040 . Bits 5:0 of the address are ignored. 
> 

> This would mean that the tags repeat every 16K. 

> Comments? 


This is news to me. Are you sure? The table describing legal cache-size configurations 
in the uarch, which includes the first- tag-address for different cache sizes, does not 
suggest this. 

If what you say is true, it needs to be clearly documented, and our software (ukernel, osf 
kernel, diagnostics, and the simulator) will need to be modified. (Absolutely no change 
will be made until there is adequate confirmation.) 


> 


> jeffm 


lisa 
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From: dickson (Richard Dickson) 
Sent: Thursday, February 09, 1995 3:01 PM 
To: 'geert'; 'hopper'; 'tor'; 'woody' 
Subject: gamorra 

you'all 

did gamorra just go down for some reason just now ??? 

HOME=/n/rama/s5/dickson/euterpe/tools LM_LICENSE_FILE=/n/rama/s5 
/dickson/euterpe/tools/sl/license/license.dat DISPLAY=demeter:0 SL_TOTAL_DURATIO 
N=500 CHIPROOT=/n/rama/s5/dickson/euterpe /n/rama/s5/dickson/euterpe/tools/bin/g 
astatus -ds gards/mst-iter ) || (mv gards/mst-iter.pcomp.lis gards/mst-iter.pcom 
p.lis.ERROR; false) 

Protocol error, gamorra.microunity.com closed connection 
gmake[5]: *** [gards/mst-iter.pcomp.lis] Error I 

gmake[5]: Leaving directory , /N/rama/root/s5/dickson/euterpe/verilog/bs^c/mst , 
gmake[4]: *** [gards/mst-iter] Error 1 

gmake[4]: Leaving directory , /N/rama/root/s5/dickson/euterpe/ve^ilog/bsrc/mst , 
gmake[3]: *** [gards/mst-iter] Error 1 

gmake[3]: Leaving directory N /N/rama/root/s5/dickson/euterpe/verilog/bsrc/mst' 
gmake[2]: *** [gards/mst-iter] Error 1 

gmake[2]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/mst' 
gmake[l]: *** [gards/mst-iter] Error I 

dickson 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, February 09, 1995 3:05 PM 

'jeffm (Jeff Marr)' 

'euterpe' 

dtag/itag addressing 


Jeff Marr wrote (on Thu Feb 9) : 

There has been a major misunderstanding about tag 
addressing. 

To access the tags, the tag address offset is 

in address bits 13:6. The address of the second dtag entry is not 
0x800000a00008, it is 0x800000a00040 . Bits 5:0 of the 
address are ignored. 

This would mean that the tags repeat every 16K. 
Comments? 

Having talked to both gmo and abbott, it appears that this is more an issue from a 
diagnostic point of view than for the real software. 
The current documentation is incomplete. 

As jeffm describes, the same address path is used for "back door" 

access to the tags as is used for normal cached accesses. This means that adjacent 
entries are 64 bytes apart in the address space. The low order bits are ignored, so in 
fact each entry actually appears 8 times in a 64 byte block of the address space. Thus, 
with the cache/buffer configured for 16K of cache, the full tag array occupies a 16K block 
of the address space and this whole block then repeats through the full 2MB of physical 
address space allocated for tags. 

Now there are some additional subtleties when the cache size if configured to less than 
16K, in respect of how the array repeats throught the 2MB of address space and some 
additional checking is being done before we make a definitive statement on this. 

In the mean time, it is the case that for both I and D with any cache size configuration, 
the tag entries are always 64 bytes apart. 

Stand by for more complete information . . . 


Tim 
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From: 


tbr 


To: 


Sent: 


Cc: 


Thursday, February 09, 1995 3:32 PM 
'dickson (Richard Dickson)' 
'geeif; 'sysadmin'; 'hopper 1 ; 'woody' 


Subject: 


gamorra 


Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Thu Feb 9): 
you'all 

did gamorra just go down for some reason just now ??? 

HOME=/n/rama/s5/dickson/euterpe/tools LM_LICENSE_FILE=/n/rama/s5 
/dickson/euterpe/tool s/sl/license/license.dat DISPLAY=demeter:0 SL TOT A LDURATIO 
N=500 CHIPROOT=/n/rama/s5/dickson/euterpe/n/rama/s5/dickson/euterpe/tools/bin/g 
astatus -ds gards/mst-iter ) || (mv gards/mst-iter.pcomp.lis gards/mst-iter.pcom 
p.Iis.ERROR; false) 

Protocol error, gamorra.microunity.com closed connection 
gmake[5]: *** [gards/mst-iter.pcomp.lis] Error 1 

gmake[5]: Leaving directory '/N/rama/root/s5/dickson/euterpe/verilog/bsrc/mst' 
gmake[4]: *** [gards/mst-iter] Error 1 

gmake[4]: Leaving directory '/N/rama/root/s5/dickson/euterpe/verilog/bsrc/mst' 
gmake[3]: *** [gards/mst-iter] Error 1 

gmake[3]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/mst' 
gmake[2]: *** [gards/mst-iter] Error 1 

gmake[2]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/mst' 
gmakefl]: *** [gards/mst-iter] Error 1 


No problem as far as I know: 

tbr@staypuft /si 409 % rsh gamorra uptime 
1 :29pm up 6 days, 2:12, 7 users, load average: 2.10, 1.93, 1.84 
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From: tbr (Tim B. Robinson) 

Sent: Thursday, February 09, 1995 3:32 PM 

To: 'dickson (Richard Dickson)' 

Cc: 'geert'; 'sysadmin'; 'hopper'; 'woody' 

Subject: gamorra 


Richard Dickson wrote (on Thu Feb 9) : 
you' all 

did gamorra just go down for some reason just now ??? 

HOME= / n/rama / s5 /dickson/euterpe/ tools 
LM_LICENSE_FILE- / n/rama/ s5 

/dickson/euterpe/ tools/ si/ license/license . dat DISPLAY=demeter : 0 SL_TOTAL_DURATIO 

N=500 CHIPROOT= /n/rama/ s5 /dickson/euterpe 
/n/rama/ s5/dickson/euterpe/tools/bin/g 

astatus -ds gards/mst- iter ) [ | (mv gards/mst- iter . pcomp . lis gards/mst-iter . pcom 

p. lis. ERROR; false) 

Protocol error, gamorra.microunity.com closed connection 

gmake[5]: *** [gards/mst- iter . pcomp . lis] Error 1 

gmake [5] : Leaving directory 
* /N/rama/root/s5/dickson/euterpe/verilog/bsrc/mst 1 

gmake [4]: *** [gards/mst-iter] Error 1 

gmake [4] : Leaving directory 
VN/rama/root/s5/dickson/euterpe/verilog/bsrc/mst ' 

gmake [3]: *** [gards/mst-iter] Error 1 

gmake [3] : Leaving directory 
VN/rama/root/s5/dickson/euterpe/verilog/bsrc/mst ' 

gmake [2]: *** [gards/mst-iter] Error 1 

gmake [2] : Leaving directory 
VN/rama/root/s5/dickson/euterpe/verilog/bsrc/mst ' 

gmake [13: *** [gards/mst-iter] Error 1 


No problem as far as I know: 

tbr@staypuft /si 409 % rsh gamorra uptime 

1:29pm up 6 days, 2:12, 7 users, load average: 2.10, 1.93, 1.84 
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From: 
Sent: 
To: 

Subject: 


Tom Karzes [karzes@scylla] 
Thursday, February 09, 1995 4:21 PM 
'software@scylla' 
genperm utility 


As some of you know, I have written a utility which generates Euterpe code sequences for 
performing arbitrary 64 -bit permutations, as well as many "extended" permutations which 
involve the replication of some bits. 

The program is called "genperm" , and is available on both the SGIs and the Suns. In both 
environments, it resides in /a/sof t/stb/bin, which is very likely already in your PATH. 

If you're interested in using genperm, or just reading about it, you should type "man 
genperm" to see the man page. However, you will probably have to add /usr /local /man/ stb 
to your MAN PATH to get it (this is a recently created symbolic link to an area which 
includes not only the man page for genperm but some other man pages as well) . 

Let me know if you have any questions, comments, suggestions, etc. 


Tom Karzes 
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From: hcbu (Herman Chu) 

Sent: Thursday, February 09, 1995 4:23 PM 

To: 'ken' 

Cc: 'hchu'; *tbr' 

Subject: Mosaic Problem on Phobos 

Hi Ken, 

I am trying to use mosaic to look up some data. I was able to bring it up, but 
it was not responding to my key board entries. 

Please let me know is there something I need to setup before using Mosaic on my 
Sun Sparc II (phobos). 

Thank you. 

Herman 


Begin Included Message 

>From geert Wed Feb 8 18:09:18 1995 

Date: Wed, 8 Feb 1995 18:09:10 -0800 

From: geert (Geert Rosseel) 

To: hchu, tbr, yves 

Subject: Re: Linear power supplies 

Cc: pandora 

Content-Length: 500 

Hi, 

Here are the specs on Cronus ( = CMOS Euterpe ) 

CSM foundry 

5V supply 

400MHz clock 

150 W power dissipation 

3 sq. cm. die size 

These numbers are preliminary estimates. 

If you want to know more about Cronus, you can use Mosaic since 
all our documentation is done using Mosaic ( Go to Muse Home page, 
follow link to chip-home, follow link to Chip-specific documentation, 
hit SET CHIPROOT, go to chip home, go to Cronus ) 


Geert 


End Included Message 
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Subject: 


Sent: 

To: 

Cc: 


From: 


mws (Mark Semmelmeyer) 
Thursday, February 09, 1995 4:30 PM 
'bobm'; 'tbr'; 'jeffm'; 'djc\ 'woody'; 'billz' 
'euterpe' 

Re: Cache Size & Aliasing (Test Status - dcacheharder2) 


> From jeffm Thu Feb 9 12:05:26 1995 
> 

> Mark Semmelmeyer writes: 


> > 


> > It think what will happen is that the overall block of a given tag 

> > array will repeat every cache_size bytes. Thus if a cache size is 

> > set to 4K, only the tags corresponding to that 4K will be accessible 

> > and repeat every 4K bytes. 
> 

> No, I didn't come to that conclusion. I think that for reading and 

> writing the cache size is irrelevent. There are 256 accessable entries 

> in the tag array, always. They are all accessable to SW, regardless of 

> the cache size. The addresses of the entries do not change. Just which 

> entries are significant changes. 

I think you are right on the ITag, since its read/write path is more direct. The DTag is 
more complicated because it is later in the pipe and uses a preempt psuedo instruction to 
do the actual access, and the generation of such instructions is somewhat tortured. There 
is a dontcare in the generation of bit 47 which will disable cache size index forcing on 
the psuedo instruction accessing the DTag. Thus it may or may not force. 

Since the I case is stable and harder to change, I consider the uncertainty in the D case 
to be a bug and will say that both I & D tags will be backdoor physical address accessible 
in their entirety regardless of cache size. It is the programmer's responsibility to use 
the correct higher address start points for smaller size caches. The entire block for one 
of the tags will alias every 16K, and as stated by tbr • s mail, each tag entry will appear 
as 8 aliases in a 64 byte chunk of the 16K block. In a future implementation, the block 
would tend to change to match the new largest configurable cache size. 

Dave Conroy is working on some tests that should force us to meet this intention even if 
the hardware currently does not, i.e. deviations are considered bugs. 
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From: ken (Ken Hsieh) 

Sent: Thursday, February 09, 1995 4:43 PM 

To: 'tbr' 

Subject: Re: Mosaic Problem on Phobos 

I have hepled him to understand how to use it. 
Ken 

> From hchu Thu Feb 9 14:23:1 1 1995 

> Date: Thu, 9 Feb 1995 14:23:08 -0800 

> From: hchu (Herman Chu) 

> To: ken 

> Subject: Mosaic Problem on Phobos 

> Cc: hchu, tbr 

> Content-Length: 1024 

> 

> Hi Ken, 

> 

> I am trying to use mosaic to look up some data. I was able to bring it up, but 

> it was not responding to my key board entries. 

> 

> Please let me know is there something I need to setup before using Mosaic on my 

> Sun Sparc II (phobos). 

> 

> Thank you. 

> 

> Herman 

> 
> 

> Begin Included Message 

> 

> >From geert Wed Feb 8 18:09:18 1995 

> Date: Wed, 8 Feb 1995 18:09:10 -0800 

> From: geert (Geert Rosseel) 

> To: hchu, tbr, yves 

> Subject: Re: Linear power supplies 

> Cc: pandora 

> Content-Length: 500 
> 

> Hi, 

> 

> Here are the specs on Cronus ( = CMOS Euterpe ) 

> 

> CSM foundry 

> 

> 5V supply 

> 400MHz clock 

> 1 50 W power dissipation 

> 3 sq. cm. die size 

> 

> These numbers are preliminary estimates. 

> 

> If you want to know more about Cronus, you can use Mosaic since 

> all our documentation is done using Mosaic ( Go to Muse Home page, 
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> follow link to chip-home, follow link to Chip-specific documentation, 

> hit SET CHIPROOT, go to chip home, go to Cronus ) 

> 
> 

> Geert 

> 
> 

> End Included Message 
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Subject: 


From: 
Sent: 
To: 


Cc: 


vanthof (vant) 

Thursday, February 09, 1995 8:14 PM 

'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'Jisar (Lisa Robinson)'; Vo (Tom Vo)'; 'tbr 
(Tim B. Robinson)' 

'vanthof (Dave Van't Hof)'; 'torn (Thomas Laidig)'; 'wampler (Kurt Wampler)'; 'paulp (Paul 

Poenisch)' 

euterpe drc status 


Here's the drc status of euterpe: 

lower layers (baseplate) 

The remaining errors were N+Implant min space violations caused 
by a defective synthesis algorithm. I've corrected this after talking 
with Paul and am about to rerun the lower layers. If this works, then 
the baseplate layers are 'clean' according to the current ruleset . 

upper layers (metals) 

This run exposed about 1000 remaining drc errors which were easily 
fixed by editing about 15 cells. These have been locked and released, 
so a getbom for the snapshot would be helpful . 

Not all of the drc errors could be fixed as they were machine generated 
by either the router or the via twinning phase. I would like to have 
a 'drc clean' database which has as few false errors as possible, so 
I'd like to come to a resolution on the automatically generated 
notches. Since it is felt that via twinning is a 'good thing', and 
notch filling is a 'good thing', I'd like to propose putting the 
notch filler in the generation of the top level layouts. This will 
generate a 'drc clean' layout which is also a highly desireable 
'good thing 1 . 


Other things: 

When I was clicking through the drc errors, Tom noticed some funny 
business with how some jogs were handled by the router. It seems that 
the routing strategy may not be quite correct. When jogging a metal 4 
line 1 grid, instead of just using metal 4 to do the jog, a via was 
placed to connect the two metal two lines which now blocks the metal 3 
track at that point. This can be seen at (157040,11255 0) in the 
snapshot euterpe. I'm not sure what I'm talking about, but it might 
be good to have some expert investigate this. 

Now for the really bizarre thing. If you look at (158565, 3615) in 
euterpe, this is the end of a metal3 'trombone'. This is a 1/2 micron 
notch of metal 3 which goes for about 2mm (2 000 MICRONS) along the 
front of the cr block. You've gotta see this one to believe it. 
Trace it out and it goes forever. . . 

I'm now starting another set of drc runs; upper on mothra, and lower on some machine. 
I'll also start another shorts test soon. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him J 


Thanks , 
Dave 
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From: tbr 

Sent: Thursday, February 09, 1995 9:16 PM 

To: 'vanthof (vant)' 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'Paul Poenisch'; 

Thomas Laidig'; 'Dave Van't Hof ; 'Tom Vo'; 'Kurt Wampler' 

Subject: euterpe drc status 

Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Thu Feb 9): 


Here's the drc status of euterpe: 

upper layers (metals) 

This run exposed about 1000 remaining drc errors which were easily 
fixed by editing about 1 5 cells. These have been locked and released, 
so a getbom for the snapshot would be helpful. 

getbom is running now. If no-one objects I'll fire up the make in a 
couple of hours when I get home. 

Other things: 

When I was clicking through the drc errors, Tom noticed some funny 
business with how some jogs were handled by the router. It seems that 
the routing strategy may not be quite correct. When jogging a metal 4 
line 1 grid, instead of just using metal 4 to do the jog, a via was 
placed to connect the two metal two lines which now blocks the metal 3 
track at that point. This can be seen at (1 57040,1 1 2550) in the 
snapshot euterpe. I'm not sure what I'm talking about, but it might 
be good to have some expert investigate this. 

That could be really significant if it happens a lot of the time. 

Now for the really bizarre thing. If you look at (158565, 361 5) in 
euterpe, this is the end of a metaB 'trombone'. This is a 1/2 micron 
notch of metal 3 which goes for about 2mm (2000 MICRONS) along the 
front of the cr block. You've gotta see this one to believe it. 
Trace it out and it goes forever... 

Can't wait! 
Tim 
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From: tbr (Tim B. Robinson) 

Sent: Thursday, February 09, 1995 9:16 PM 

To: 'vanthof (vant)' 

Cc: 'geert (Geert Rossee!)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'paulp (Paul 

Poenisch)'; 'torn (Thomas Laidig)'; Vanthof (Dave Van't Hot)'; 'vo (Tom Vo)'; 'wampler (Kurt 
Warn pier)' 

Subject: euterpe drc status 


vant wrote {on Thu Feb 9) : 


Here's the drc status of euterpe: 

upper layers (metals) 

This run exposed about 1000 remaining drc errors which were easily- 
fixed by editing about 15 cells. These have been locked and released, 
so a getbom for the snapshot would be helpful . 

getbom is running now. If no-one objects I'll fire up the make in a couple of hours when 
I get home. 

Other things: 

When I was clicking through the drc errors, Tom noticed some funny 
business with how some jogs were handled by the router. It seems that 
the routing strategy may not be quite correct. when jogging a metal 4 
line 1 grid, instead of just using metal 4 to do the jog, a via was 
placed to connect the two metal two lines which now blocks the metal 3 
track at that point. This can be seen at (157040,112550) in the 
snapshot euterpe. I'm not sure what I'm talking about, but it might 
be good to have some expert investigate this. 

That could be really significant if it happens a lot of the time. 

Now for the really bizarre thing. If you look at (158565, 

3615) in 

euterpe, this is the end of a metal3 'trombone'. This is a 1/2 micron 
notch of metal 3 which goes for about 2mm (2000 MICRONS) along the 
front of the cr block. You've gotta see this one to believe it. 
Trace it out and it goes forever. . . 

Can't wait! 
Tim 
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To: 


Subject: 


Cc: 


Sent: 


From: 


tbr 

Thursday, February 09, 1995 9:33 PM 
'woody' 

'dickson'; 'lisar' 
Hermes error packets 


Follow Up Flag: Follow up 
Flag Status: Red 

What would happen if the hermes interface on Euterpe receives several 
error packets in fairly close succession? My guess is that it will 
just result in single machine check. This is a case that could well 
occur with a channel error when there are multiple mnemosynes in the 
ring so I want to be sure it will not result in a double machine 
check. I think we need to be sure the channel will ignore further 
errors till the machine check handler disables and re-enables the 
channel 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Thursday, February 09, 1 995 1 1 : 1 3 PM 

To: Vanthof (vant)' 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'paulp (Paul 

Poenisch)'; 'torn (Thomas Laidig)'; Vanthof (Dave Van't Hof)'; Vo (Tom Vo)'; 'wampler (Kurt 
Warn pier)' 

Subject: euterpe drc status 


vant wrote (on Thu Feb 9) : 

upper layers (metals) 

This run exposed about 10 0 0 remaining drc errors which were easily 
fixed by editing about 15 cells. These have been locked and released, 
so a getbom for the snapshot would be helpful . 

getbom is complete, make is running now. Should I page anyone when it completes? 

Tim 
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From: vanthof (vant) 

Sent: Thursday, February 09, 1995 11:17 PM 

To: Tim B. Robinson' 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'paulp (Paul 

Poenisch)'; 'torn (Thomas Laidig)'; Vo (Tom Vo)'; 'wampler (Kurt Wampler)' 
Subject: Re: euterpe drc status 


Tim B . Robinson writes : 

>vant wrote (on Thu Feb 9) : 
> 

> upper layers (metals) 

> This run exposed about 1000 remaining drc errors which were 
easily 

> fixed by editing about 15 cells. These have been locked and 
released, 

> so a getbom for the snapshot would be helpful. 
> 

>getbom is complete. make is running now. should I page anyone when it 

>completes? 

> 

>Tim 


Nope, not me. I've got all I need right now. If any reroute is done, I'll start up 
another drc tomorrow, but tonight things are fine. 

Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

25 5 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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Sent: 
To: 

Cc: 


From: 


wampler (Kurt Wampler) 
Thursday, February 09, 1995 11:49 PM 
'geert'; 'hopper*; 'lisar'; 'tor'; 'vanthof ; 'vo' 


Subject: 


'paulp'; 'torn'; 'wampler' 
Re: euterpe drc status 


Dave Van't Hof writes: 


>When I was clicking through the drc errors, Tom noticed some funny 
>business with how some jogs were handled by the router. It seems that 
>the routing strategy may not be quite correct. When jogging a metal 4 
>line 1 grid, instead of just using metal 4 to do the jog, a via was 
>placed to connect the two metal two lines which now blocks the metal 3 
>track at that point. This can be seen at £157040,112550) in the 
>snapshot euterpe. I'm not sure what I'm talking about, but it might be 
>good to have some expert investigate this. 

I had a look at this case. There is apparently a routing target at the 
site 157040 112560, and I would hazard a guess that the net was routed 
in two different passes, perhaps one part by the linesearch router and 
then finished up by the maze router or some such. Same -layer doglegs are 
performed as a post-processing pass, but only on actual jogs. If the 
first hookup was a straight shot, and then the second hookup was an 
"L", then the router would not recognize an "S" convertible to a same-layer 
dogleg. Another clue is that there are two via34 ' s attached to the target. 
I don't believe the router would do this if both hookups were completed 
in the same pass. But if the two hookups were completed in different 
passes, I believe it would generate a redundant via on the 2nd pass hookup. 

>Now for the really bizarre thing. If you look at (158565, 3 615) in 
>euterpe, this is the end of a metal3 'trombone'. This is a 1/2 micron 
>notch of metal 3 which goes for about 2mm (2000 MICRONS) along the 
>front of the cr block. You've gotta see this one to believe it. 
>Trace it out and it goes forever . . . 

This one is really weird. It seems to hook up to pin PHI_B on the cell CR. 
The trombone would appear to be avoiding some no- longer-visible metal3 
obstruction. Could this be a "hwc" net gone awry, where the hwc mask 
no longer falls in the proper place? 

If the " .dff" file is still around, I think it would be worth finding this 
one in REDIT and seeing if we can identify it and when it got routed. 


- Kurt 
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From: vanthof (vant) 

Sent: Thursday, February 09, 1 995 1 1 :56 PM 

To: 'Kurt Wampler' 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; lisar (Lisa Robinson)'; 'tbr (Tim B. 

Robinson)'; Vo (Tom Vo)'; 'paulp (Paul Poenisch)'; 'torn (Thomas Laidig)'; 'vanthof (Dave Van't 
Hof}' 

Subject: Re: euterpe drc status 


Kurt Wampler writes: 

> 

> I had a look at this case. There is apparently a routing target at 

> the site 157040 112560, and I would hazard a guess that the net was 

> routed in two different passes, perhaps one part by the linesearch 

> router and then finished up by the maze router or some such. 

> Same- layer doglegs 
are 

> performed as a post -processing pass, but only on actual jogs. If the 

> first hookup was a straight shot, and then the second hookup was an 

> " L" , then the router would not recognize an "S" convertible to a 
same -layer 

> dogleg. Another clue is that there are two via34's attached to the 
target . 

> I don't believe the router would do this if both hookups were 

> completed in the same pass. But if the two hookups were completed in 

> different passes, I believe it would generate a redundant via on the 

> 2nd pass 
hookup . 

Oh. See, I knew I didn't know what I was talking about :-) 


>>Now for the really bizarre thing. If you look at (158565, 3615) in 
>>euterpe, this is the end of a metal3 'trombone'. This is a 1/2 micron 
>>notch of metal 3 which goes for about 2mm (2000 MICRONS) along the 
>>front of the cr block. You've gotta see this one to believe it. 
>>Trace it out and it goes forever... 
> 

> This one is really weird. It seems to hook up to pin PHI_B on the 

> cell 
CR. 

> The trombone would appear to be avoiding some no- longer-visible 

> metal 3 obstruction. Could this be a "hwc" net gone awry, where the 

> hwc mask no longer falls in the proper place? 
> 

> If the ".dff" file is still around, I think it would be worth finding 
this 

> one in RED IT and seeing if we can identify it and when it got routed. 
> 

> - Kurt 


Thanks for looking into these! 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me , I didn ' t vote for him ! 
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From: woody (Jay Tomlinson) 

Sent: Friday, February 10, 1995 12:12 AM 

To: 'for (Tim B. Robinson)' 

Cc: 'dickson'; 'lisar' 

Subject: Hermes error packets 


Tim B. Robinson wrote (on Thu Feb 9): 

What would happen if the hermes interface on Euterpe receives several 
error packets in fairly close succession? My guess is that it will 
just result in single machine check. This is a case that could well 
occur with a channel error when there are multiple mnemosynes in the 
ring so I want to be sure it will not result in a double machine 
check. I think we need to be sure the channel will ignore further 
errors till the machine check handler disables and re-enables the 
channel 

Tim 

Once the error is set, he will hold it until an CErrClr_abm is received 
(assuming that the channel is enabled). Does the CErrClr come after the reset? 
If yes, then why is the CErrClr needed since the channel is disabled by reset. 

Inside of he CErrClr_abm is converted to eel, but not synchronized. Is there some 
reason why this isn't synchronized? 

Jay 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Friday, February 10, 1995 12:33 AM 
'woody (Jay Tomlinson)' 
'dickson'; 'lisar' 
Hermes error packets 


Follow Up Flag: Follow up 
Flag Status: Red 

Jay Tomlinson wrote (on Thu Feb 9): 

Tim B. Robinson wrote (on Thu Feb 9): 

What would happen if the hermes interface on Euterpe receives several 
error packets in fairly close succession? My guess is that it will 
just result in single machine check. This is a case that could well 
occur with a channel error when there are multiple mnemosynes in the 
ring so I want to be sure it will not result in a double machine 
check. I think we need to be sure the channel will ignore further 
errors till the machine check handler disables and re-enables the 
channel 


Once the error is set, he will hold it until an CErrClrabm is received 
(assuming that the channel is enabled). Does the CErrClr come after the reset? 
If yes, then why is the CErrClr needed since the channel is disabled by reset. 

Channel is not disabled by reset. Cerrclr results from an explicit 
write to octlet 7. 

Inside of he CErrClr_abm is converted to eel, but not synchronized. Is there some 
reason why this isn't synchronized? 

Yes. Since it's being used just to clear the flag the leading edge is 
not important because it would just determine when the flag gets 
cleared. A cycle of uncertainty is not important in practice. 
Neither is the trailing edge relevant because the flag should stay 
down independent of the clear is there is not a new error condition. 


Tim 


Tim 
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From: dickson (Richard Dickson) 

Sent: Friday, February 10, 1995 2:09 AM 

To: 'geert'; 'hopper'; 'tor' 

Subject: system ??? 


you 1 all , 

i'm finding the computer system very flakey. 
it sucks . 

Savings by squeezing out extra time = (29244 - 29244) = 0.00% Change from original input 
power = (29244 - 29244) = 0.00% 

NOTE: 2241 unpowered nets. 

NOTE; 91 nets with delays less than 50.00ps 

Atoms: count atom bjt isrc pld clock 

BJT Totals; 7325 45827 107943 66433 60820 28661 

Memory usage: 33.500MB 
Exit code: 5 (System Error) 
gmake[6]: *** [gards/es-iter] Error 1 
gmake [6] : Leaving directory 

VN/rama/root/s5/dickson/euterpe/verilog/bsrc/esnew ' 
gmake [5]: *** [gards/es-iter] Error 1 
gmake [5] : Leaving directory 

VN/rama/root/ s5/dickson/euterpe/verilog/bsrc/esnew' 
gmake [4]: *** [gards/es-iter] Error 1 
gmake [4]: Leaving directory 

VN/rama/root/ s5/dickson/euterpe/verilog/bsrc/esnew' 
gmake [3]: *** [gards/es-iter] Error 1 
gmake [3]; Leaving directory 

* /N/rama/root/s5/dickson/euterpe/verilog/bsrc/esnew' 
gmake [2]: *** [gards/es-iter] Error 1 

and .... 

Reading 4 89 existing regions 

Active placement obstructions: 0 
Inactive placement obstructions: 0 
Non- conflicting delay obstructions: 4 89 
Conflicting delay 15 obstructions: 0 (deleted) 
New delay 15 obstructions: 190 (loaded) 
sh: /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke: Stale NFS file handle ###SHELL### cat 
$CHlPROOT/gards/sof a/sof a_pads_spars .obs datapath. obs 
> combo. obs 

###SHELL### $CHIPROOT/tools/bin/galoadobs rich_euterpe-iter . df f combo. obs ###SHELL### 
$CHIPROOT/tools/bin/gasavepins rich_euterpe-iter.df f ###GAROUT### 
/n/rama/s5/dickson/euterpe/tools/sl/bin/ invoke garout 
rich_euterpe- 

iter -listing rich_euterpe- iter .garout . lis .phasel -protectpins 2 
-strategy ric 

h_euterpe -iter .mug . rcf . 1 -congval rich_euterpe- iter . mug . cvp . 1 

cp: gards/rich_euterpe- iter . garout . lis : No such file or directory 

gmake [2]: *** [gards/rich_euterpe- iter .garout . lis] Error 1 

gmake [2]: Leaving directory VN/rama/root /s5/dickson/euterpe/verilog/bsrc ' 

gmake [1]: *** [rich_euterpe- iter] Error 1 rm rich_euterpe . v 

gmake [1] : Leaving directory VN/rama/root /s5/dickson/euterpe/verilog/bsrc ' 

gmake: *** [rich_euterpegards] Error 1 

page queued 

starting paged 

these kinds og things in the recent past is waisting man-days 
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From: geert (Geert Rosseel) 

Sent: Friday, February 10, 1995 9:27 AM 

To: 'hopper'; 'lisar*; 'tbr'; 'vanthof ; 'vo'; 'wampler* 

Cc: 'paulp'; 'torn' 

Subject: Re: euterpe drc status 

> If the ".dfT file is still around, I think it would be worth finding this 

> one in REDIT and seeing if we can identify it and when it got routed 

All the data still should be in the euterpe snapshot . this build is 
called chip_euterpe-iter 

The euterpe snapshot is in /n/auspex/s41 
Geert 
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From: hopper (Mark Hofmann) 

Sent: Friday, February 10, 1995 9:43 AM 

To: 'sysadm'; 'woody (Jay Tomlinson)'; 'dickson (Richard Dickson)'; 'cadettes' 
Subject: More machine-machine weird ness 


Hi, 

On my latest Gards run I just got this: 

(echo "cd 'abspathVgards; \ 

HOME=/n/auspex/s32/h opper/ch i p/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/s32/hopper/chip/euterpe/tools/sl/license/license.dat DISPLAY=hardO 1 5 .microunity.com :0 
SL_TOTAL_DURATION=500 

CHIPROOT=/n/auspex/s32/hopper/chip/euterpe /n/auspex/s32/hopper/chip/euterpe/tools/s1/binyinvoke gplace gt-pass3 - 
listing gt-pass3.gplace.lis -cmdin gt-pass3. gplace. nic -colorin gt-pass3. gplace. mobi23 4 -inbat 1" j \ 

/usr/local/bin/rexec cyclops sh && HOME=/n/auspex/s32/hopper/chip/euterpe/too1s 
LM_LICENSE_FILE=/n/auspex/s32/hopper/chip/euterpe/tools/sl/license/license.datDISPLAY=hard015.mi 
SL_TOTAL_DURATION=500 

CHIPROOT=/n/auspex/s32/hopper/chip/euterpe /ii/auspex/s32/hopper/chip/euterpe/tools/bin/gastatus -sp gards/gt-pass3) || 
(mv gards/gt-pass3. gplace. lis gards/gt-pass3 .gplace. lis. ERROR; rm -f gt-pass3.nof; false) 
cyclops: unknown host 
logging rsh error 
aupexO: unknown host 

cp: /usr/tmp/named.run: No such file or directory 

cp: /usr/tmp/named.run: No such file or directory 

cp: /usr/tmp/named.run: No such file or directory 

cp: /usr/tmp/named.run: No such file or directory 

mv: gards/gt-pass3.gptace.lis: Cannot access: No such file or directory 

gmake[2]: *** [gards/gt-pass3. gplace. lis] Error 1 

gmake[2]: Leaving directory , /N/auspex/root/s32/hopper/chip/euterpe/verilog/bsrc/gt' 
gmake[lj: *** [gt-base.netcap] Error 1 

gmake[lj: Leaving directory , /N/auspex/root/s32/hopper/chip/euterpe/verilog/bsrc/gt' 
gmake: *** [gtgards] Error 1 

Note that I was on Cyclops at the time. 

Rich Dickson reported a "system error" (code 5 - physical I/O) last night. 
I believe he was also on Cyclops. 

We need to get to the bottom of these. 

Anybody got any ideas? 

Any experiments you want me to try? 

-thanks, 
hopper 
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From: paulp (Paul Poenisch) 

Sent: Friday, February 10, 1995 10:10 AM 

To: Vant* 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'vo (Tom Vo)'; 'tbr 

(Tim B. Robinson) 1 ; 'torn (Thomas Laidig)'; 'wampler (Kurt Wampler)' 
Subject: Re: euterpe drc status 

Dave van't Hof said: 
> 

> Here 1 s the drc status of euterpe : 
> 

> lower layers (baseplate) 

> The remaining errors were N+Implant min space violations caused 

> by a defective synthesis algorithm. I've corrected this after 
talking 

> with Paul and am about to rerun the lower layers. If this works, 
then 

> the baseplate layers are 'clean' according to the current ruleset. 
> 

> upper layers (metals) 

> This run exposed about 1000 remaining drc errors which were easily 

> fixed by editing about 15 cells. These have been locked and 
released, 

> so a getbom for the snapshot would be helpful . 

> 

> Not all of the drc errors could be fixed as they were machine 
generated 

by either the router or the via twinning phase. I would like to 


have 
> 

so 
> 

and 
will 


a 'drc clean' database which has as few false errors as possible, 

I'd like to come to a resolution on the automatically generated 
notches. Since it is felt that via twinning is a 'good thing', 

notch filling is a 'good thing' , I'd like to propose putting the 
notch filler in the generation of the top level layouts. This 

generate a 'drc clean' layout which is also a highly desireable 

> • good thing ' . 
> 

Just to put in my 2 cents. . . 

The metal process isn't stable enough yet, and we haven't done enough experiments or taken 
ennough data points yet, but so far it appears that narrow notches in the metal {i.e., 0.5 
urn) are more suseptable to lift-off problems than other structures. This is based on 
artifacts on structures that lifted properly. This indicates to me that when the process 
fails, due to process variations, it will fail at these notches first. Eliminating the 
notches should widen the process margin for lift-off, eliminating most of the notches of 
this size but leaving a few will (on any given layer) will not benifit us much because it 
won't matter if the prcess fails at one site or 10,000. 
Note 

that these structures will not cause random defects so the density of them has little 
improtance, the important factor is their presents or absents. 

It this time we do not know what the margin of our lift-off process will be, and we aren't 
likely to know what it is for some time (months) . As a result I believe that we should do 
whatever we can to improve the margin now in case it is a problem because it will be more 
difficult to fix (either by redesign or process changes) later. Also it is better to 
eliminate possible problem areas on a single layer than to reduce them on all layers, the 
best action is to eliminate them on all layers. 

> 

> Other things : 

> When I was clicking through the drc errors, Tom noticed some funny 
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■> business with how some jogs were handled by the router. It seems 

that 

> the routing strategy may not be quite correct. When jogging a 
metal 4 

> line 1 grid, instead of just using metal 4 to do the jog, a via 
was 

> placed to connect the two metal two lines which now blocks the 
metal 3 

> track at that point. This can be seen at (157040,112550) in the 

> snapshot euterpe . I'm not sure what I'm talking about, but it 
might 

> be good to have some expert investigate this. 
> 

> Now for the really bizarre thing. If you look at (158565, 3615) 
in 

> euterpe, this is the end of a metal3 'trombone'. This is a 1/2 
micron 

> notch of metal 3 which goes for about 2mm (20 00 MICRONS) along the 

> front of the cr block. You've gotta see this one to believe it. 

> Trace it out and it goes forever. . . 
> 

> I'm now starting another set of drc runs; upper on mothra, and lower 

> on some machine. I'll also start another shorts test soon. 

> 

> Thanks, 

> Dave 


> Dave Van't Hof vanthof@microunity.com MicroUnity Systems 
Engineering , Inc . 

> 255 Caspian Way, Sunnyvale, CA (4 08) 73 4-8100 X276 #include 
<std_disclaim.h> 

> Don't blame me, I didn't vote for him! 


Paul . 
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To: 


Subject: 


Cc: 


Sent: 


From: 


tbr 

Friday, February 10, 1995 11:09 AM 
'dickson (Richard Dickson)' 
'geert'; 'hopper' 
system ??? 


Follow Up Flag: Follow up 
Flag Status: Red 

Richard Dickson wrote (on Fri Feb 1 0): 
you'all, 

i'm finding the computer system very flakey. 
it sucks. 

Savings by squeezing out extra time = (29244 - 29244) = 0.00% 
Change from original input power = (29244 - 29244) = 0.00% 

NOTE: 2241 unpowered nets. 

NOTE: 91 nets with delays less than 50.00ps 

Atoms: count atom bjt isrc pld clock 

BJT Totals: 7325 45827 107943 66433 60820 28661 

Memory usage: 33.500MB 
Exit code: 5 (System Error) 
gmake[6]: *** [gards/es-iter] Error 1 

gmake[6]: Leaving directory , /N/rama/root/s5/dickson/euterpe/verilog/bsrc/esnew t 
gmake[5]: *** [gards/es-iter] Error 1 

gmake[5]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/esnew' 
gmake[4]: *** [gards/es-iter] Error 1 

gmake[4j: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/esnew' 
gmake[3]: *** [gards/es-iter] Error I 

gmake[3]: Leaving directory ^/rama/root/sS/dickson/euterpe/verilog/bsrc/esnew' 
gmake[2]: *** [gards/es-iter] Error 1 

Error 5 is a physical I/O error. Was this actually running on 
cyclops? If we know the machine we can check the logs carefully 
for possible trouble. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Friday, February 1 0, 1 995 1 1 :09 AM 

To: 'dickson (Richard Dickson)' 

Cc: 'geert'; 'hopper' 

Subject: system ??? 


Richard Dickson wrote (on Fri Feb 10) : 
you' all, 

i'm finding the computer system very flakey. 
it sucks. 

Savings by squeezing out extra time = (29244 - 29244) = 0.00% 
Change from original input power = (29244 - 29244) = 0.00% 

NOTE: 2241 unpowered nets. 

NOTE: 91 nets with delays less than 50.00ps 

Atoms: count atom bjt isrc pld clock 

BJT Totals: 7325 45827 107943 66433 60820 28661 

Memory usage: 33.50 0MB 

Exit code: 5 (System Error) 

gmake [6]: *** [gards/es- iter] Error 1 

gmake [6] : Leaving directory 
VN/rama/root/ s5/dickson/euterpe/verilog/bsrc/esnew' 

gmake [5]: *** [gards/es- iter] Error 1 

gmake [5] : Leaving directory 
VN/rama/root/sS/dickson/euterpe/verilog/bsrc/esnew' 

gmake [4]: *** [gards/es- iter] Error 1 

gmake [4] : Leaving directory 
VN/rama/root/sS/dickson/euterpe/verilog/bsrc/esnew' 

gmake [3]: *** [gards/es- iter] Error 1 

gmake [3] : Leaving directory 
" /N/rama/root/s5/dickson/euterpe/verilog/bsrc/esnew ' 

gmake [2]: *** [gards/es-iter] Error 1 

Error 5 is a physical I/O error. Was this actually running on cyclops? If we know the 
machine we can check the logs carefully for possible trouble. 
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From: lisar (Lisa Robinson) 

Sent: Friday, February 1 0, 1 995 1 1 :28 AM 

To: 'staffers' 

Subject: Schedule todo's and issues 


Here are some of the outstanding schedule todos. Note that while some are just doing it a 
couple of others may require discussion. I have *ed the critical issues. 


Euterpe 
Mnemosyne 
* Cronus 

♦Calliope 2 
* Pandora SW 
Pandora OEM Selection 


- Add wafer test and characterization 

- Complete 

- Add logic verification, back end LVS/DRC 

- Link in to top 

Driven by a production Hestia?? 

- Needs more resources 

Who is actually doing the work here 


(indeed it may be already be done)? 

- Agree upon a level in design effort and 


Pandora Industrial Design 
incorporate 

Pandora Chassis and Enclosure 
dependancies 

Pandora Regulatory 

Pandora Bringup 

*? Mixed Signal Modules 

Hestia continuing engineering 


Add correct durations and refine 
Add 

Need add details 

Not much here yet, but is that critical? 
Update current schedule 


The will be some discussion at the Pandora meeting today. 
Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Friday, February 10, 1995 11:41 AM 

Vanthof 

'geert'; 'hopper 1 ; 'lisar'; 'paulp'; 'tbr'; 'torn'; Vo' 
Re: euterpe drc status 


More discussion of bizarre M3 trombone: 


@>>Now for the really bizarre thing. If you look at (15 8565, 3615) in @>>euterpe, this is 
the end of a metal3 'trombone'. This is a 1/2 micron @>>notch of metal 3 which goes for 
about 2mm (2000 MICRONS) along the @>>front of the cr block. You've gotta see this one to, 
believe it. 

@>>Trace it out and it goes forever... 
@> 

@> This one is really weird. It seems to hook up to pin PHI_B on the cell CR. 
@> The trombone would appear to be avoiding some no- longer- visible metal3 @> 
obstruction. Could this be a "hwc" net gone awry, where the hwc mask @> no longer falls 
in the proper place? 
@> 

@> If the ".dff" file is still around, I think it would be worth finding this @> one in 

REDIT and seeing if we can identify it and when it got routed. 

@> 

@> - Kurt 

@> 

@ 

©Thanks for looking into these! 
©Dave 

Thanks, Geert, for pointing me at the .dff file. This wire was generated 
by PGROUTE, and it's part of net PHI_B2P. The PGROUTEr is a 
line-search- 
only router that only works in the first two metal layers (in this case 
MOBI layers M2 & M3 , the way we have modelled the technology to GARDS 
for global routing) . It needed to hook up to the PHI_B target on custom 
block CR, but was prevented from using M2 to do so by a large flange of 
M20BS along the entire west edge of CR. It routed successfully to the 
PHI_A target using M3 only, which blocked off its approach to the PHI_B 
target . The trombone extends all the way to the south end of the M20BS 
flange, where it made a one-track eastward jog in M2 , and then headed back 
up north in M3 to hit the PHI_B target. After "succeeding" in this way, 
the dog- leg post-processor converted the one-track M2 jog into a M3 jog 
and removed the vias, leaving the trombone. 

The fix would be to trim back the M20BS flange around the PHI_A and PHI_B 
targets so that the PGROUTEr can reach them horizontally in M2 . There is 
good nearby PHI_A2P and PHI_B2P available from the adjacent clock 
spar, but this obvious best hookup was thwarted by the M20BS flange. 

By the way, whomever looks at this one in Compass, pay attention to both 
M20BS and actual M2; I can't tell in REDIT whether that flange came from 
the metal obstruction layer or the real metal layer. Both layers may need 
trimming . 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


graham (Graham Y. Mostyn) 
Friday, February 10, 1995 12:35 PM 
'staffers'; 'lisar' 

Re: Schedule todo's and issues 


A meeting was called by David and I to finalize the RF module proposal at 1.30pm with Tony 
and others, and we'll report the results at 3pm. 
Graham . 

> From lisar Fri Feb 10 09:27:45 1995 

> Date: Fri, 10 Feb 1995 09:27:41 -0800 

> From: lisar (Lisa Robinson) 

> To: staffers 

> Subject: Schedule todo's and issues 

> Content -Length: 1098 
> 

> 

> Here are some of the outstanding schedule todos. Note that while some 

> are just doing it a couple of others may require discussion. I have 

> *ed the critical issues. 


> Euterpe 
> 

> Mnemosyne 
> 

> * Cronus 
LVS/DRC 

> 

> *Calliope 2 

> 

> * Pandora SW 

> 

> Pandora OEM Selection 
(indeed it may be already be done)? 
> 

> Pandora Industrial Design 
and incorporate 
> 

> Pandora Chassis and Enclosure 
dependancies 
> 

> Pandora Regulatory 
> 

> Pandora Bringup 
> 

> *? Mixed Signal Modules 
critical? 


Add wafer test and characterization 
Complete 

Add logic verification, back end 
Link in to top 

Driven by a production Hestia?? 
Needs more resources 
Who is actually doing the work here 

- Agree upon a level in design effort 

- Add correct durations and refine 

- Add 

- Need add details 

- Not much here yet, but is that 


> Hestia continuing engineering - Update current schedule 


> The will be some discussion at the Pandora meeting today. 

> 

> Lisa R. 
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From: torn (Tom Laidig (tau)) 

Sent: Friday, February 10, 1995 12:41 PM 

To: 'Kurt Wampler' 

Cc: Vanthof (Dave Van't Hof)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa 

Robinson)'; 'paulp (Paul Poenisch)'; 'tbr (Tim B. Robinson)'; 'vo (Tom Vo)'; 'tau' 
Subject: Re: euterpe drc status 


Kurt Wampler writes: 

The trombone extends all the way to the south end of the j 
M20BS flange, where it made a one-track eastward jog in M2 , and then ! 
headed 
back 

| up north in M3 to hit the PHI_B target. After "succeeding" in this 
way, 

| the dog- leg post-processor converted the one-track M2 jog into a M3 
j jog and removed the vias, leaving the trombone. 

I 

Cool 1 (and good detective work, Kurt J ) 

I'm really glad we stumbled onto this problem, but it makes me a bit nervous. Is there 
some way we can put in an automated check for unreasonably long clock connections 
(whatever "unreasonably long' 
means) ? 
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From: warnpler (Kurt Wampler) 

Sent: Friday, February 10, 1995 1:07 PM 

To: 'torn* 

Cc: 'geeif ; 'hopper*; 'lisar 1 ; 'paulp'; 'tau'; 'tbr'; Vanthof ; Vo' 

Subject: Re: euterpe drc status 


Kurt Wampler writes: 

The trombone extends all the way to the south end of the 
M20BS flange, where it made a one- track eastward jog in M2, and then 
headed 
back 

1 up north in M3 to hit the PHI_B target. After "succeeding" in this 
way, 

] the dog- leg post -processor converted the one-track M2 jog into a M3 
| jog and removed the vias, leaving the trombone. 

Tom L. replies: 


>Cool! (and good detective work, Kurt!) 
> 

>I'm really glad we stumbled onto this problem, but it makes me a bit 
>nervous . Is there some way we can put in an automated check for 
unreasonably long clock connections (whatever "unreasonably long' 
>means) ? 

If these were what GARDS considers signal nets, they would show up as 
unexpectedly long wires and would fail timing. GARDS PG nets like PHI_ [AB] 2P 
are inherently very long, and so can't be subjected to this simple 
total-net- length criterion. Looking at their database documentation, they 
do have segment & via lists for each of the PG nets. It would be possible to 
write a GEARS program which scan these segment lists and output the 
coordinates of any PG routing segments longer than some stated length 
threshold. Someone would then have to manually view each of these long PG 
segments in RED IT and pass judgment on their validity. I'm not sure how 
many long segments might be legitimate, or where to set the length 
threshold. 

If we're collectively curious enough about this, I could cobble up the 
GEARS program to perform this check and see what turns up. Comments? 

- Kurt 
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From: woody (Jay Tomlinson) 

Sent: Friday, February 10, 1995 3:51 PM 

To: 'sysadmin' 

Cc: 'tbr'; 'geerf; 'dickson' 

Subject: gamorra problem? 

I got the following error message from gamorra (protocol error): 

HOME=/n/auspex/s 1 0/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/s 1 0/ch ip/euterpe/tools/s 1/1 icense/1 icense.dat DISPLAY=clio:0.0 

SL TOTAL DURATION=500 CHIPROOT=/n/auspex/s 1 0/chip/euterpe /n/auspex/sIO/chip/euterpe/tools/bin/gastatus -ds 

gards/hcl -pass 1 ) || (mv gards/hcl -pass l.pcomp. lis gards/hc 1 -pass l.pcomp. lis. ERROR; false) 

Protocol error, gamorra.microunity.com closed connection 

mv: gards/hcl -pass l.pcomp. lis: Cannot access: No such file or directory 

gmake[2]: *** [gards/hcl -pass l.pcomp.lis] Error 1 

gmake[2]: Leaving directory '/N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc' 
gmake[l]: *** [hcl-base.netcap] Error 1 

gmake[l]: Leaving directory '/N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc' 
gmake: *** [hclgards] Error 1 

dickson got the same message yesterday. This message is in a file: 
/u/chip/euterpe/verilog/bsrc/hc/gards/makerrs 1 . 

woody 
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From: tbr 

Sent: Friday, February 10, 1995 6:30 PM 

To: 'hopper (Mark Hofmann)' 

Cc: 'cadettes'; 'dickson (Richard Dickson)'; 'sysadm'; 'woody (Jay Tomlinson)' 

Subject: More machine-machine weirdness 
Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Fri Feb 10): 


Hi, 

On my latest Gards run I just got this: 

(echo "cd 'abspauY/gards; \ 

HOME=/n/auspex/s32/hopper/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/s32/hopper/chip/euterpe/tools/sl/license/l icense.dat DISPLAY^iard015.microunity,com:0 
SL_TOTAL_DURATION-500 

CHIPROOT=/n/auspex/s32/hopper/chip/euterpe /n/auspex/s32/hopper/chip/euterpe/tools/sl/bin/invoke gplace gt-pass3 - 
listing gt-pass3 .gplace. lis -cmdin gt-pass3. gplace. nic -colorin gt-pass3.gplace.mobi234 -inbat 1" | \ 

/usr/local/bin/rexec cyclops sh && HOME=/n/auspex/s32/hopper/chip/euterpe/tools 
LM_LICENSE_FILE=/nyauspex/s32/hopper/chip/euterpe/tools/sl/license/l icense.dat DISPLA Y=hard0 1 5 .microunity .com :0 
SL_TOTAL_DURATION=500 

CHIPROOT=/n/auspex/s32/hopper/chip/euterpe /n/auspex/s32/hopper/chip/euterpe/tools/bin/gastatus -sp gards/gt-pass3) ]| 
(mv gards/gt-pass3.gplace.lis gards/gt-pass3.gpIace.lis.ERROR; rm -f gt-pass3.nof; false) 

cyclops: unknown host 

logging rsh error 

aupexO: unknown host 

cp: /usr/tmp/named.run: No such file or directory 

cp: /usr/tmp/named.run: No such file or directory 

cp: /usr/tmp/named.run: No such file or directory 

cp: /usr/tmp/named.run: No such file or directory 

mv: gards/gt-pass3.gplace.lis: Cannot access: No such file or directory 

gmake[2]: *** [gards/gt-pass3 .gplace. lis] Error 1 

gmake[2]: Leaving directory , /N/auspex/root/s32/hopper/chip/euterpe/verilog/bsrc/gt' 
gmakefl]: *** [gt-base.netcap] Error 1 

gmake[l]: Leaving directory , /N/auspex/root/s32/hopper/chip/euterpe/verilog/bsrc/gt' 
gmake: *** [gtgards] Error 1 

Note that I was on Cyclops at the time. 

Rich Dickson reported a "system error" (code 5 - physical I/O) last night. 
I believe he was also on Cyclops. 


We need to get to the bottom of these. 

Anybody got any ideas? 

Any experiments you want me to try? 

-thanks, 
hopper 

correction, rich sent the mail from cyclops, but the jobs that dies 
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were on gamorra and ghidra: 


Richard Dickson wrote (on Fri Feb 10): 
tim, 

one job was running on ghidra and the other job was running 
on gamorra. i just happened to email you guys from a cyclops 
window, they both paged me at the same time, i believe there 
was some correlation between both jobs bombing out. 
after i emailed y'all i restarted both the jobs and they finished. 
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From: geert (Geert Rosseel) 
Sent: Friday, February 1 0, 1 995 6:48 PM 
To: 'bill'; 'paulp'; 'tbr'; 'trancy'; 'wingard' 
Subject: MCM test tape-out 

Hi, 

Can we meet on Monday at 4:00 p.m. to discuss the feasibility 
of a simple test tape-out to CSM and MicroModule ? 

Hardware Conference Room 
Geert 
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From: geert (Geert Rosseel) 
Sent: Friday, February 10, 1995 6:51 PM 
To: 'bill'; 'dbulbef; 'lisar'; 'toe'; 'tbr' 
Subject: Cronus Module 


Hi, 

Can we meet on Monday morning 1 1 :00 a.m. to discuss the system 
level implications on the Cronus chip-design. We are trying to 
finalize specifications on the chip and there seem to be a 
couple of loose ends .. 

Thank's 

Geert 

Monday Feb. 13 
1 1 a.m. 

Hardware Conference Room 
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From: paulp (Paul Poenisch) 

Sent: Friday, February 1 0, 1 995 7:20 PM 

To: 'Geert Rosseel' 

Subject: Re: MCM test tape-out 


Monday at 4:00 is OK with me. 
Paul . 
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From: Buffalo Chip [chip@rhea] 

Sent: Friday, February 10, 1995 7:28 PM 

To: 'geert^rhea' 

Subject: pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/gt BOM 73.0 initiated by hopper completed @ Fri Feb 10 
17:27:22 PST 1995 with exit status 0.. chip 
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Subject: 


To: 
Cc: 


From: 
Sent: 


vanthof (vant) 

Friday, February 10, 1995 10:01 PM 
Tom Vo' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)' 
Re: mnemo baseplate 


Tom Vo writes : 
> 

>Hi , 


> 


>If there CPU cycles available , here's a mnemo baseplate to keep the 

>machines busy . 

> 

>/n/ghidra/s4/vo/lisar/mnemo/compass/baseplate/mnemo. ly . 
> 

>This version still did not see all the updated pdl so it's no good for 
>LVS . it's should be OK for DRC though . 


I've submitted an upper and lower drc for mnemo. When the shorts check for one corner of 
euterpe finishes, the mnemo drc ' s will start up. If however, there is still a short in 
euterpe, I'm going to kill the mnemo drc to track down the lvs short in euterpe. 

Thanks for the info . 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std__disclaim. h> Don't blame 
me, I didn't vote for him! 


> 


> thanks 
> 

>tvo 


> 
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From: geert (Geert Rosseel) 

Sent: Friday, February 10, 1995 11:41 PM 

To: 'tbr'; Vanthof 

Subject: New Euterpe is building 

Hi, 

I started up a new euterpe build on gamorra. Should be done by tomorrow 
morning. 

Geert 
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From: vanthof (vant) 

Sent: Saturday, February 11, 1995 12:33 AM 

To: 'Geert RosseeP 

Cc: Vanthof (Dave Van't Hof)'; 'tbr (Tim B. Robinson)' 

Subject: Re: New Euterpe is building 


Geert Rosseel writes: 
> 

> Hi, 
> 

> I started up a new euterpe build on gamorra. Should be done by 
>tomorrow morning. 

> 

> Geert 

Thanks. I'll start up some more drc ' s and shorts checks tomorrow. I've got some mnemo 
drc's running tonight, but the metals should be done by tomorrow night. 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

2 55 Caspian Way, Sunnyvale, CA (408) 734-8100 X2 76 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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From: hopper (Mark Hofmann) 

Sent: Saturday, February 11,1995 5:08 AM 

To: 'vant' 

Cc: 'geert (Geert Rosseel)'; "tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; Tom Vo'; 'Dave Van't Hof 
Subject: Re: drc/shorts status 

vant writes: 
Here's the status of euterpe and mnemo: 

euterpe lower drc's: 

It's got another day to run, but the intermediate results show 

a two new drc errors flags dealing with poly silicide and contact ped. 

No big deal, but needs to be fixed. 

Okay. Any indication of which cell(s) may be the culprit? 

euterpe upper drc's: 

as of yesterday, they were as clean as I could get them. The remaining 
errors are from the router and via twinner which will be filled by 
Tom's notch filler. 

Geert has regenerated some new layouts and upper and lower drc's are 
resubmitted. 

euterpe shorts checks: 

The upper right corner shorts check came back clean. This is one corner 
where previous shorts checks failed. Hopefully this is a good indicator 
the shorts have been removed. 

A new shorts check has been submitted and will start sometime early 
next week. 

Mnemo upper and lower drc's: 

both are running! The uppers should be done late tonight and the 
lower sometime monday. 

Cool! I notice all the machines are in use! 

Hopefully we'll get a couple faster Sparc chips on Monday which will help out. 


The floating poly check is not working quite correct yet. It finds shorts 
which are not real, but do affect the results. I'm working on fixing this. 

Tiz all for now. 
Dave 

-hopper 
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From: hopper (Mark Hofmann) 

Sent: Saturday, February 11, 1995 5:30 AM 

To: 'Geert Rosseel' 

Cc: Vo (Tom Vo)' 

Subject: Re: gt dies in snapshot 


Geert Rosseel writes: 

/n/auspex/s41/euterpe- snapshot /euterpe/verilog/bsrc/gt 
I think it is pifpack which causes a fatal error 

Yes. 

Damn. I'll have it fixed in 5 minutes. 

Sorry, 
-mark 
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From: hopper (Mark Hofmann) 

Sent: Saturday, February 1 1 , 1995 5:39 AM 

To: 'Geert Rosseel' 

Cc: 'vo (Tom Vo)' 

Subject: Re: gt dies in snapshot 


Geert Rosseel writes: 

/n/auspex/s41/euterpe- snapshot /euterpe/verilog/bsrc/gt 
I think it is pifpack which causes a fatal error 

Okay. 

I've released a new version of pifpack. I had a typo. Try it again. 
(I'm running a testcase also) . 

-hopper 
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From: geert (Geert Rosseel) 

Sent: Saturday, February 11, 1995 11:06 AM 

To: 'lisar 1 

Cc: W 

Subject: Re: Proteus make finished 

I got the page and started up a new euterpe. It is done already, 
thank's 
Geert 
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From: lisar (Lisa Robinson) 

Sent: Saturday, February 11, 1995 12:33 PM 

To: 'mws'; 'woody' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'tbr' 

Subject: icachemiss 


This foiled. There is a likedriverlog trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/l 1295.1 1622. 
Looks like a problem with taking an interrupt. 
I'm trying to get a dump now. 

nbtulltest went to bad. I haven't looked at this one yet. 

Lisa R. 
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From: vanthof (vant) 

Sent: Saturday, February 11, 1995 12:34 PM 

To: 'Geert Rosseel' 

Cc: Vanthof (Dave Van't Hof)' 

Subject: Re: Euterpe done 

Geert Rosseel writes: 
> 

> Hi Dave, 
> 

> Euterpe build is done. 
> 

> Geert 


Thanks' I'll submit another set of drc ' s . They probably won't start until later this 
weekend . 

Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ^include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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From: vanthof (vant) 

Sent: Saturday, February 1 1 , 1 995 1 :03 PM 

To: 'geert (Geert Rosseel)'; 'hopper (Mark Hoffmann)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa 

Robinson)'; Vo (Tom Vo)' 
Cc: 'vanthof (Dave Van't Hof)' 

Subject: drc/shorts status 


Here's the status of euterpe and mnemo: 

euterpe lower drc 1 s : 

It's got another day to run, but the intermediate results show 

a two new drc errors flags dealing with poly silicide and contact ped. 

No big deal, but needs to be fixed. 

euterpe upper drc 1 s : 

as of yesterday, they were as clean as I could get them. The remaining 
errors are from the router and via twinner which will be filled by 
Tom's notch filler. 

Geert has regenerated some new layouts and upper and lower drc ' s are 
resubmitted. 

euterpe shorts checks: 

The upper right corner shorts check came back clean. This is one corner 
where previous shorts checks failed. Hopefully this is a good indicator 
the shorts have been removed. 

A new shorts check has been submitted and will start sometime early 
next week. 

Mnemo upper and lower drc ' s : 

both are running! The uppers should be done late tonight and the 
lower sometime monday. 


The floating poly check is not working quite correct yet. It finds shorts which are not 
real, but do affect the results. I'm working on fixing this. 

Tiz all for now. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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From: Curtis Abbott [abbott@tallis] 
Sent: Saturday, February 11, 1995 1:12 PM 
To: 'tbr@tallis' 
Subject: discussion 

I came looking for you Friday — can we hook up Monday sometime for a 
chat? I want to ask some Euterpe questions of a sensitive nature. 

- Curtis 
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From: tbr 

Sent: Saturday, February 1 1 , 1 995 1 :59 PM 

To: 'geert (Geert Rosseel)' 

Subject: Cronus Module 

Follow Up Flag: Follow up 
Flag Status: Red 


This is going to conflict with mouss's VP pre-meeting 
Geert Rosseel wrote (on Fri Feb 1 0): 


Hi, 

Can we meet on Monday morning 1 1 :00 a.m. to discuss the system 
level implications on the Cronus chip-design. We are trying to 
finalize specifications on the chip and there seem to be a 
couple of loose ends .. 


Thank's 


Geert 


Monday Feb. 13 
1 1 a.m. 

Hardware Conference Room 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, February 1 1 , 1 995 1 :59 PM 

To: 'geert (Geert Rosseel)' 

Subject: Cronus Module 


This is going to conflict with mouss's VP pre-meeting 
Geert Rosseel wrote (on Fri Feb 10) : 


Hi, 

Can we meet on Monday morning 11:00 a.m. to discuss the system 
level implications on the Cronus chip -design. We are trying to 
finalize specifications on the chip and there seem to be a 
couple of loose ends . . 

Thank ' s 
Geert 

Monday Feb. 13 
11 a.m. 

Hardware Conference Room 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Saturday, February 11, 1995 2:07 PM 

'geert (Geert Rosseel)' 

Vanthof 

New Euterpe is building 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Fri Feb 1 0): 
Hi, 

I started up a new euterpe build on gamorra. Should be done by tomorrow 
morning. 

Glad you got the page OK. I didn't for some reason. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, February 1 1 , 1 995 2:07 PM 

To: 'geert (Geert Rosseel)' 

Cc: Vanthof 

Subject: New Euterpe is building 


Geert Rosseel wrote {on Fri Feb 10) : 


I started up a new euterpe build on gamorra. Should be done by tomorrow 
morning . 

Glad you got the page OK. I didn't for some reason. 
Tim 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Saturday, February 11, 1995 3:53 PM 
■geert' 
datapath 


geert , 


i'm not off by much fitting everything to the rigth of x = 222 6. since the blocks 
grow a little when i put them together in rich_euterpe gards i have to use the 
rich_euterpe gards placement data and go back and update the standalone placements, 
(ie i have to go completely around the loop to make the necessay improvements and this 
takes alot of cpu cycles) i'll continue to push. 

i ■ 11 probably finish sometime this weekend, i'll keep you posted. 


dickson 
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From: 


tbr 


Sent: 
To: 

Subject: 


Saturday, February 11, 1995 5:57 PM 
'Curtis Abbott' 


discussion 


Follow Up Flag: Follow up 
Flag Status: Red 

Curtis Abbott wrote (on Sat Feb 1 1): 

I came looking for you Friday — can we hook up Monday sometime for a 
chat? I want to ask some Euterpe questions of a sensitive nature. 

Sure. Calendar is looking pretty full, but right after lunch might 


work. 


Tim 


Exhibit Cll 


Page 239 of 559 


Sent: 

To: 

Cc: 


From: 


Subject: 


tbr 

Saturday, February 11, 1995 6:41 PM 

'Tom Eich' 

•dbulfer' 

DECISION IMMINENT: Fanless Euterpe Module 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Thu Feb 2): 
DECISION IMMINENT FOR PANDORA EUTERPE MODULE TO BE COOLED BY SYSTEM LEVEL FAN. 

Shou this now get promoted to a FINAL DECISION? 


Tim 
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From: 
Sent: 
To: 

Subject: 


Tom Eich [tbe@MicroUnity.com] 

Saturday, February 11, 1995 7:36 PM 

, pandora@MicroUnity.corrr 

FINAL DECISION: Fanless Euterpe Module 


The Euterpe module in Pandora will not have an integral cooling fan. The system level 
blowers will provide the required airflow for Euterpe and the SDRAMs. 

(Cronus module status is pending review with Geert et al in light of the reversion to the 
5V design and consequent dissipation. A separate message will be issued relative to the 
Cronus module in Pandora . ) 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
2 55 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, (408)734-8136 fax 


tbe@microunity . com 
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From: Tom Eich [tbe@MicroUnity.com] 
Sent: Saturday, February 11, 1995 7:43 PM 
To: 'tbr'; 'dbulfer' 

Subject: Re: DECISION IMMINENT: Fanless Euterpe Module 

tbr wrote: 

>Tom Eich wrote (on Thu Feb 2): 

> 

> DECISION IMMINENT FOR PANDORA EUTERPE MODULE TO BE COOLED BY SYSTEM LEVEL 
>FAN. 

> 
> 

>Shou this now get promoted to a FINAL DECISION? 

> 

>Tim 

Yes-note the reference in the FINAL DECISION post to the Cronus module. 
At -100W for the purported 3.3 design, the system level blower approach was 
fairly easily extended from its application in a Euterpe based Pandora, 
since we are planning to use temperature controlled fans. In light of the 
return to 5Vdc and -150W, I thought it prudent to allow Herman and myself 
time to layout and analyze for this case, since the power dissipation is no 
longer similar to Euterpe. We are meeting at 10:00 am Monday to discuss 
(I've forwarded Geert's message to Herman) and I will post an Imminent and 
then Final decision messages after concluding preliminary analysis, this 
week I hope. 

-Tom 


Tom Eich j tbe@microunity.com 

MicroUnity Systems Engineering, Inc.j 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Saturday, February 11, 1995 7:51 PM 

Tom Eich' 

•dbulfer 1 

Re: DECISION IMMINENT: Fanless Euterpe Module 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Sat Feb 11): 

Yes-note the reference in the FINAL DECISION post to the Cronus module. 
At -100W for the purported 3.3 design, the system level blower approach was 
fairly easily extended from its application in a Euterpe based Pandora, 
since we are planning to use temperature controlled fans. In light of the 
return to 5Vdc and ~150W, I thought it prudent to allow Herman and myself 
time to layout and analyze for this case, since the power dissipation is no 
longer similar to Euterpe. We are meeting at 10:00 am Monday to discuss 
(I've forwarded Geert's message to Herman) and I will post an Imminent and 
then Final decision messages after concluding preliminary analysis, this 
week I hope. 

OK, good points. 


Tim 
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From: geert (Geert Rosseel) 

Sent: Saturday, February 11, 1995 9:39 PM 

To: 'tbr' 

Cc: 'sysadmin' 

Subject: Re: ISDN question 

Thank's Tim, I'll try that 

I need the DISPLAY locally because I want to do mincut on the top-level 
Euterpe. 

Geert 


Exhibit Cll 


Page 244 of 559 


Subject: 


From: 


Sent: 

To: 

Cc: 


tbr (Tim B. Robinson) 

Saturday, February 11, 1995 10:35 PM 

'fwo (Fred Obermeier)' 

'bpw'; 'geert' 

Csyn Euterpe BOM 223 errors 


Fred Obermeier wrote (on Wed Feb 8) : 


Hi, 


Csyn now performs more stringent checks on wired emitter (w) and 
wired collector (y) nodes. If one uses a #w or #y, then the # 
must match among all the driver nodes. If one uses numberless 
w or y, then all drivers must use the same numberless w and/or y. 
More restrictive checks will follow. 

The Output Short check errors found in tbr_euterpe-passl . spivs 
generated from bsrc BOM 22 3.0 are listed below. Please let 
me know when these errors have been fixed. 

< big snip > 

Looks like all of this is in the tlb. BP, has this been corrected, or will we need 
another snapshot update to deal with it? 


Tim 
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From: tbr 

Sent: Saturday, February 11, 1995 11:02 PM 

To: 'wampler (Kurt Wampler)' 

Cc: 'geert'; 'hopper'; 'lisar'; 'paulp'; 'tau'; 'torn'; Vanthof ; Vo* 

Subject: Re: euterpe drc status 
Follow Up Flag: Follow up 

Flag Status: Red 


Kurt Wampler wrote (on Fri Feb 10): 

Kurt Wampler writes: 

I 

j The trombone extends all the way to the south end of the M20BS 
| flange, where it made a one-track eastward jog in M2, and then headed back 
| up north in M3 to hit the PHI_B target. After "succeeding" in this way, 
j the dog-leg post-processor converted the one-track M2 jog into a M3 jog 
j and removed the vias, leaving the trombone. 

Tom L. replies: 


>Cool! (and good detective work, Kurt!) 

> 

>I'm really glad we stumbled onto this problem, but it makes me a bit 
>nervous. Is there some way we can put in an automated check for 
unreasonably long clock connections (whatever ' unreasonably long' 
>means)? 

If these were what GARDS considers signal nets, they would show up as 
unexpectedly long wires and would fail timing. GARDS PG nets like PHI_[AB]2P 
are inherently very long, and so can't be subjected to this simple 
total-net-length criterion. Looking at their database documentation, they 
do have segment & via lists for each of the PG nets. It would be possible to 
write a GEARS program which scan these segment lists and output the 
coordinates of any PG routing segments longer than some stated length 
threshold. Someone would then have to manually view each of these long PG 
segments in REDIT and pass judgment on their validity. I'm not sure how 
many long segments might be legitimate, or where to set the length 
threshold. 

If we're collectively curious enough about this, I could cobble up the 
GEARS program to perform this check and see what turns up. Comments? 

Sounds like this could be worthwhile. On a normal net we ought to 
pick it up as a timing violation, but on a clock net like this 
it could end up being a killer skew problem. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 11, 1995 11:02 PM 

'wampler (Kurt Wampler)' 

'geert'; 'hopper'; 'lisar'; 'paulp'; 'tau'; 'torn'; 'vanthof ; Vo' 
Re: euterpe drc status 


Kurt Wampler wrote (on Fri Feb 10) : 


Kurt Wampler writes : 


The trombone extends all the way to the south end of the 


M20BS 


| flange, where it made a one-track eastward jog in M2, and then headed back 

j up north in M3 to hit the PHI_B target. After "succeeding" in this way, 

j the dog- leg post-processor converted the one-track M2 jog into a M3 jog 

I and removed the vias, leaving the trombone. 

Tom L. replies: 


>Cool! (and good detective work, Kurt!) 
> 

>I»m really glad we stumbled onto this problem, but it makes me a bit 
>nervous. Is there some way we can put in an automated check for 
unreasonably long clock connections (whatever "unreasonably long 1 
>means) ? 

If these were what GARDS considers signal nets, they would show up as 
unexpectedly long wires and would fail timing. GARDS PG nets like PHI_[AB]2P 
are inherently very long, and so can't be subjected to this simple 
total-net -length criterion. Looking at their database documentation, they 
do have segment & via lists for each of the PG nets. It would be possible to 
write a GEARS program which scan these segment lists and output the 
coordinates of any PG routing segments longer than some stated length 
threshold. Someone would then have to manually view each of these long PG 
segments in REDIT and pass judgment on their validity. I'm not sure how 
many long segments might be legitimate, or where to set the length 
threshold. 

If we're collectively curious enough about this, I could cobble up the 
GEARS program to perform this check and see what turns up. Comments? 

Sounds like this could be worthwhile. On a normal net we ought to pick it up as a timing 
violation, but on a clock net like this it could end up being a killer skew problem. 


Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Sunday, February 12, 1995 1:49 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 85.0 initiated by woody completed @ Sat Feb 11 
23:46:40 PST 1995 with exit status 0.. chip 
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From: 


lisar (Lisa Robinson) 

Sunday, February 12, 1995 2:18 PM 

'mws' 


Sent: 


To: 


Cc: 'billz'; 'dickson'; 'jeffm'; 'tbr'; 'woody' 
Subject: BOM 229 - Great 


Fixed icachemiss and nbfulltest. No suprises so far .... 


Design Name: i_euterpe_wrap 
Run Date: 12295 
Run ID: 9348 


Simulator: i_euterpe_wrap.ioj was built on Sun Feb 12 4:53:26 1995 
Using BOM: Version BOM,v 229.0 1995/02/12 01:53:03 LT mws 
Warning: Local BOM is out of date ... 
Log Message: 

testl0_0 Ran ok 
load_0 Ran ok 
store_unique_0 Ran ok 
cystoreload_0 Ran ok 
memtest_0 Ran ok 
ibuf storeeasy O Ran ok 
itagstoreeasyO Ran ok 
dtag storeeasy 0 Ran ok 
ltlb_0 Ran ok 
gtlb_0 Ran ok 
gtlbaccess4_0 Ran ok 
gtlbmisseasy O Ran ok 
dcacheeasy_0 Ran ok 
dcacheharderO Ran ok 
dcacheannoying_0 Take a look at this ... 
0 0000800000C0004C0000800000C0004C @1598403.000 NS 
0 FFFFFFFFFFFFFFFE0000800000C00060 @ 1598409.000 NS 
0 00000000000000000000000000000000 @1598415.000NS 
0 0000800000C002080000800000C00208 @ 1598421. 000 NS 
0 0000800000C002100000800000C00210@1598427.000 NS 
0 FFFFFFFFFFFFFFFFOO008000OOC0OO60 @1598433.000 NS 
0 00000000000000000000000000000000 @ 1598439.000 NS 
0 00000000000000080000000000000008 @1598445.000 NS 

0 0000800000C002080000800000C00208 @1 598451 .000 NS 

1 00OO0000OO000FABO00OO000000O0FAB @ 1 598457.000 NS 
0 00000000000000000000000000000000 @1598463.000 NS 

0 00000000000000080000000000000008 @1 598469.000 NS 

0 0000800000C0004C0000800000C0004C @1598475.000 NS 

1 00OO0OO00OO00BAD0OOO00000OO00BAD @ 159848 1.000 NS 

Failed 

dcachenoalloc O Ran ok 
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icacheharder_0 Ran ok 
icachemissO Ran ok 
icacheannoyingO Ran ok 
nbuseeasyO Ran ok 
nbfulltestj) Ran ok 
nbhiprio_p Ran ok 
dram_load_0 Ran ok 
dramstoreuniqueO Ran ok 
dramharder_0 Ran ok 
bdovvnharder_0 No result 
sysprotol_l No result 
sysproto2_l No result 
cerbeasy 0 No result 
knobharderj) No result 
Total number cycles run = 2915833 
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From: 
Sent: 
To: 


Cc: 

Subject: 


vanthof (vant) 

Sunday, February 12, 1995 11:19 PM 

'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)'; 'lisar (Lisa Robinson)'; Vo (Tom Vo)'; 'tbr 
(Tim B. Robinson)' 
Vanthof (Dave Van't Hof)' 
drc/lvs status 


The euterpe lower drc ' s came back with about 6 or 7 new errors . I have not looked at them 
yet so I don't know what's causing the errors. 

euterpe upper and lower are rerunning from Geert ' s last reroute. 

The euterpe shorts check is still running and I'll know by the morning if there are any 
more shorts. 

Mnemo upper drc ' s finished and it's about 3.7MB. Not bad for a first run. 
Mnemo lower drc ' s are still running. 


Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 


255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim .h> Don't blame 
me, I didn't vote for him! 
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From: hopper (Mark Hofmann) 

Sent: Monday, February 1 3, 1 995 2:44 AM 

To: 'Jay Tomlinson' 

Cc: 'sysadm' 

Subject: Re: pim2pof error 

Jay Tomlinson writes: 
hopper, 

I got the following when trying to make uu. 
[snip] 

/n/auspex/s20/woody/chip/euterpe/tools/src/pim2pof/multiPim.awk: Command not found. 

Looks like more machine-machine weirdness. 
I just did : 

Is -I /n/auspex/s20/woody/chip/euterpe/tools/src/pim2pof/multiPim.awk 
and got : 

-rwxr-xr-x 1 chip 2002 Dec 6 06:24 /n/auspex/s20/woody/chip/euterpe/tools/src/pim2pof/multiPim.awk 

All I can say is, try your run again. 

-thanks, 
hopper 
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From: solo (John Campbell) 

Sent: Monday, February 13, 1995 9:15 AM 

To: 'B. P. Wong' 

Cc: 'tbr (Tim B. Robinson)'; 'bpw (B. P. Wong)'; 'fwo (Fred Obermeier)'; 'geert (Geert Rosseel)'; 

'hopper (Mark Hofmann)' 
Subject: Re: Csyn euterpe bom 223 


as B. P. Wong was saying 

..The changes have not been implemented yet for 2 reasons. Firstly we are ..implementing 
some drc fixes and this weekend is the when solo will running ..the large lvs runs. I do 
not want any schematic node name change to cause . .any problems with the lvs run. Once 
the lvs comes out clean then we can . .go back and edit the GTLB database again. 

. .The second reason is that we have just gone through a fix of the vref . .node names not 
too long ago and now this vwy names start croping out. 

..When will this end? We can't continually punish those that finish ..their projects 
first by continually moving the target. 

..At this point in time we are strapped against another schedule -- the ..CMOS euterpe 
which is quite important that we do not slip on this project . .and this petty changes will 
detract our attention. □[ .. 

..Here is my commitment: As soon as the lvs comes back clean then the changes ..to fix 
the csyn errors will be implemented. 

. .bpw 


regards, 

solo a.k.a. John Campbell x516 
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From: lisar (Lisa Robinson) 
Sent: Monday, February 13, 1995 9:21 AM 
To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr 1 ; 'woody' 
Subject: Test status 


BOM 229 running on Zycad 
BOM 229 running on IKOS 

New business 


brmisseasy_0 229 - Failed, trying to get dump, onchip _0 ran okay 

brmisstest_0 229 - Failed 

sysproto 1 ,2 229 - No dump yet 

exlltest2 229- 


229 

229 - went to bad (expected) 
229 


exlocktest_0 
exl5test 
exrleasy 
exresgcmpritestlj) } 
exresgexpitestl_0 } 
exresgmshr itest 1 _0 } 

exresgrotritestl_0 } 229 - all went to bad (expected) 

exresgshlitestl_0 } 

exresgshritestl_0 } 

exresgucmpritestl_0 } 

exresguexpitestl_0 } 

exresgushritestl 0 } 

Old Business - Need to reun and if necessary redump these 


dcacheharder2_0 
dcacheharder3_0 

dcache_sz_4k_l 
dcache_sz_8k_l 
dcache_sz_16k_l 

icache_fimc_l 

watchtest 

xlujie1d_5_l 

icache_sz_4k_1 
icache_sz_8k_l 
icache_sz_16k_l 

uncruptharder_0 
dcache tunc 1 


223 - Bad - trace on rhodan /s3 6295. 1 8639 - _V dump on rhodan /s3 
223 - Bad - trace on rhodan /s3 7295.9430 - _V dump on rhodan /s3 

223 - went to X } Traces in /n/rhodan/s3/euterpe/verilog/bsrc/res/7295 . 1 9339 

223 - went to X } 

223 - X - trace on rhodan /s3 6295. 1 5970 

223 New trace in 6295. 1 8837 on rhodan /s3 

223 - X - Doesn't seem to be taking a machine check, trying to get a dump 

223 - X - trace /n/rhodan/s3/euterpe/verilog/bsrc/res/4295.29774 trying to get a dump 

223 } traces in 5295.7249 Jeff these are for you! 
223 } 
223 } 

220 - Dump on nosferatu /s2 

216 - hung dcachenoalloc NEW dump available -tbr 


218 - trace in /n/rhodan/s3/euterpe/verilog/bsrc/res/ 1295.1 1572, recreating with smaller test dram ex 
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bgateJJ 


cerbarbeasyO 
gtlb_miss_l 
Need sync ops: 
saaseasy 


Lisa R to run again as verilog run is well behaved 
223 - X rhodan /s3 8295.13771 


218 - Dump on nosferatu /s2 - Problem understood 
218 


saastest_0 
scastest_0 
nb slow 
nb_l 
nbhermesl 
nb_combo_l 
dcache_stress_l 
dcache _perf_ldst5t_ 1 
icache_stress_l 
icache_perf_5t 1 
align_at_l 


223 - Running a longgggg time trace on rhodan /s3 7295.19105 


fva_conflict_l 
hermesconflictl 
dcache_conflict_l 
atomic_conflict_l 

oc-synch_U 
synch_l 

Have not yet been run: 


doubleextestO 
doublemctest_0 

cerbstarttest_0 - Need to build a "custom" simulator 
iorupttest_0 

ruptpintestO - Need to build a "custom" simulator 

dcacheexcepM 

dcache j>erfjd 1 1_ 1 
dcache_perf_stl t_l 
dcache_perf_ldstlt_l 


addr_map_dram 

interrupt_l 
cachel 
exceptionl 
bgate 1 
barreM 

interrupt_U 

exception_U 

bgate_U 

mem U 

tlbU 

synchU 

barrel_U 

cache_U 

gtlb_miss_U 
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Cannot yet be run: 


instr_U 

instrl 

tlb_l 

insn_l 

null test 

unix 

XLU tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand__l_l 

x lu_compress_ 1 _ 1 

xlu_extract_l_l 

xlufieldll 

xlu_field_2_l 

xlujield_3_l 

xlu_field_4_l 

xlucopy swap_ 1 _ 1 

xlu_copy swap_2_ 1 

xlu_copy swap_3_ 1 

xlu_copy swap_4_ 1 

xlu_shufflemux_ 1 _ 1 

xlu_select__l_l 

Not yet implemented: 


brcolltestj) 

brcrosstest_0 

brimm longtest_0 

expriotestO 

canceltestO 

hermtotestO 

cerbtotest_0 

hermcrrtcst_0 

eventregtest_0 

exintbashtest_0 

cerbregistersO 

cerberrorj) 

testerinit 0 

memmap_0 

nbbashtestO 

cerbrawO 

cerbarbtests 

hcplltests 
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Subject: 


Sent 

To: 

Cc: 


From: 


solo (John Campbell) 

Monday, February 13, 1995 9:50 AM 

'B. P. Wong' 

'tbr (Tim B. Robinson)'; 'bpw (B. P. Wong)'; 'fwo (Fred Obermeier)'; 'geert (Geert Rosseel)'; 
'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)' 
Re: Csyn euterpe bom 223 


as B . P . Wong was saying 


..The changes have not been implemented yet for 2 reasons. Firstly we are ..implementing 
some drc fixes and this weekend is the when solo will running ..the large lvs runs. I do 
not want any schematic node name change to cause . .any problems with the lvs run. Once 
the lvs comes out clean then we can . .go back and edit the GTLE database again. 

..The second reason is that we have just gone through a fix of the vref ..node names not 
too long ago and now this vwy names start croping out. 

..When will this end? We can't continually punish those that finish ..their projects 
first by continually moving the target. 

..At this point in time we are strapped against another schedule -- the ..CMOS euterpe 
which is quite important that we do not slip on this project . .and this petty changes will 
detract our attention. □[ . . 

..Here is my commitment: As soon as the lvs comes back clean then the changes ..to fix 
the csyn errors will be implemented. 


No large lvs were run this weekend. The lvs i run is on the released database and should 
not be used as a check for mdunit edits. this will corrupt our databases unnecessarily 
and introduce totally unintended errors as in this instance where dave and i decided not 
to run. now, if these new layouts are released they could corrupt runs of several days. 

it is still the responsibility of the engineer to check his own work unless i buy into 
checking it for him. i am not likely to do that at this stage of a chip. 


. . bpw 


regards , 

solo a.k.a. John Campbell 


x516 
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From: tbr 

Sent: Monday, February 13, 1995 10:54 AM 

To: 'solo (John Campbell)' 

Cc: 'bpw {B. P. Wong)'; 'B. P. Wong'; 'fwo (Fred Obermeier)'; 'Geert Rosseel'; 'Mark Hofmann'; 

'Lisa Robinson' 

Subject: Re: Csyn euterpe bom 223 

Follow Up Flag: Follow up 

Flag Status: Red 

John Campbell wrote (on Mon Feb 13): 
as B. P. Wong was saying 


..The changes have not been implemented yet for 2 reasons. Firstly we are 
..implementing some drc fixes and this weekend is the when solo will running 
..the large lvs runs. I do not want any schematic node name change to cause 
..any problems with the lvs run. Once the lvs comes out clean then we can 
..go back and edit the GTLB database again. 

..The second reason is that we have just gone through a fix of the vref 
..node names not too long ago and now this vwy names start croping out. 

..When will this end? We can't continually punish those that finish 
..their projects first by continually moving the target. 

..At this point in time we are strapped against another schedule — the 
..CMOS euterpe which is quite important that we do not slip on this project 
..and this petty changes will detract our attention. □[ 

..Here is my commitment: As soon as the lvs comes back clean then the changes 
..to fix the csyn errors will be implemented. 

..bpw 


No large lvs were run this weekend. The lvs i run is on the released 
database and should not be used as a check for mdunit edits, this 
will corrupt our databases unnecessarily and introduce totally 
unintended errors as in this instance where dave and i decided not to 
run. now, if these new layouts are released they could corrupt runs 
of several days. 

it is still the responsibility of the engineer to check his own work 
unless i buy into checking it for him. i am not likely to do that at 
this stage of a chip. 

I get the impression from fwo that this may be a problem with csyn 
being over-agressive and that this should be passing. I think we need 
to be really clear on that before wasting time making edits and 
potentially introducing new problems. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Monday, February 13, 1995 10:54 AM 

"solo (John Campbell)' 

'bpw (B. P. Wong)'; 'B. P. Wong'; 'fwo (Fred Obermeier)'; 'geert (Geert Rosseel)'; 'hopper 
(Mark Hofmann)'; 'lisar (Lisa Robinson)' 
Re: Csyn euterpe bom 223 


John Campbell wrote (on Mon Feb 13) : 
as B. P. Wong was saying 


The changes have not been implemented yet for 2 reasons. Firstly we are 
implementing some drc fixes and this weekend is the when solo will running 
the large lvs runs. I do not want any schematic node name change to cause 
any problems with the lvs run. Once the lvs comes out clean then we can 
go back and edit the GTLB database again. 

The second reason is that we have just gone through a fix of the vref 
node names not too long ago and now this vwy names start croping out. 

When will this end? We can't continually punish those that finish 
their projects first by continually moving the target. 

At this point in time we are strapped against another schedule -- the 
CMOS euterpe which is quite important that we do not slip on this project 
and this petty changes will detract our attention. □[ 

Here is my commitment: As soon as the lvs comes back clean then the changes 
to fix the csyn errors will be implemented. 


No large lvs were run this weekend. The lvs i run is on the released 
database and should not be used as a check for mdunit edits. this 
will corrupt our databases unnecessarily and introduce totally 
unintended errors as in this instance where dave and i decided not to 
run. now, if these new layouts are released they could corrupt runs 
of several days. 

it is still the responsibility of the engineer to check his own work 
unless i buy into checking it for him. i am not likely to do that at 
this stage of a chip. 

I get the impression from fwo that this may be a problem with csyn being over-agressive 
and that this should be passing. I think we need to be really clear on that before 
wasting time making edits and potentially introducing new problems. 


bpw 


Tim 
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From: woody (Jay Tomlinson) 

Sent: Monday, February 1 3, 1 995 1 1 :26 AM 

To: 'hopper (Mark Hofmann)' 

Cc: 'sysadm' 

Subject: Re: pim2pof error 

Mark, 

I found the problem. It's /usr/local/bin/gawk that is not found. If I Is -1 1 
get: 

godzilla:[uu] Is -1 /usr/local/bin/gawk 

lrwxrwxrwx 1 root 20 Jul 25 1992 /usr/local/bin/gawk -> .,/pkg/gawk/bin/gawk 
godzi!la:[uu] Is -1 /usr/local/pkg 

lrwxrwxrwx 1 root 22 Mar 3 1 1 992 /usr/local/pkg -> /n/sun/usr/local.d/pkg/ 
godzilla:[uu] Is -1 /n/sun/usr/local.d/pkg/gawk 

lrwxrwxrwx 1 root 9 Jul 25 1992 /n/sun/usr/local.d/pkg/gawk -> gawk-2.13 

godzilla:[uu] Is -1 /n/sun/usr/local.d/pkg/gawk-2. 1 3 

lrwxrwxrwx 1 root 24 Jul 25 1992 /n/sun/usr/local.d/pkg/gawk-2. 13 ->/n/rama/s6/gnu/gawk-2. 13 
godzi!la:[uu] Is -1 /n/rama/s6/gnu/gawk-2.13 
/n/rama/s6/gnu/gawk-2.13 not found 

Is something wrong with wrong with rama? 
woody 

Mark Hofmann wrote (on Mon Feb 13): 
Jay Tomlinson writes: 
hopper, 

I got the following when trying to make uu. 
[snip] 

/n/auspex/s20/woody/chip/euterpe/tools/src/pim2pof/multiPim.awk: Command not found. 

Looks like more machine-machine weirdness. 
I just did : 

Is -1 /n/auspex/s20/woody/chip/euterpe/tools/src/pim2pof/multiPim . awk 
and got : 

-rwxr-xr-x 1 chip 2002 Dec 6 06:24 /n/auspex/s20/woody/chip/euterpe/tools/src/pim2pof/multiPim.awk 

All I can say is, try your run again. 

-thanks, 
hopper 
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From: bpw (B. P. Wong) 

Sent: Monday, February 13, 1995 11:29 AM 

To: 'tbr' 

Cc: 'bpw'; 'fwo'; 'geert'; 'hopper'; 'lisar'; 'solo' 

Subject: Re: Csyn euterpe bom 223 


> I get the impression from fwo that this may be a problem with csyn 

> being over-agressive and that this should be passing. I think we need 

> to be really clear on that before wasting time making edits and 

> potentially introducing new problems. 
> 

> Tim 
> 

This is fair, I appreciate it. I guess Fred will let me know if I need to fix those node 
names . 

Rgds, 

bpw 
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From: lisar (Lisa Robinson) 

Sent: Monday, February 1 3, 1 995 1 1 :49 AM 

To: 'craig'; 'lisar' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Mon Feb 13 09:48:31 PST 1995 

Copy number: 285 

Copy registered to: Deepak Tripathi 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore . macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter lpr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: fwo (Fred Obermeier) 

Sent: Monday, February 13, 1995 12:23 PM 

To: 'bpw'; 'tbr* 

Cc: 'fwo'; 'geert'; 'hopper'; 'lisar'; 'solo' 

Subject: Re: Csyn euterpe bom 223 


BPW writes: 
> 

> > 

> > I get the impression from fwo that this may be a problem with csyn 

> > being over-agressive and that this should be passing. I think we 

> > need to be really clear on that before wasting time making edits and 

> > potentially introducing new problems. 

> > 

> > Tim 

> > 

> This is fair, I appreciate it. I guess Fred will let me know if I 

> need to fix those node names. 

> 

> Rgds, 
> 

> bpw 


Csyn, like euterpe is continully improving. Csyn rules are changed so that a consistent 
naming strategy helps us identify wiring errors. 

I don't know how most of the designs are supposed to be wired. I need feedback from 
designers if you think that csyn is wrong in reporting a false error as well as errors you 
may know of that csyn hasn 1 t caught . 

In this case, I spoke with a number of people about the OutputShorts check, and 
suggestions were made of how to appropriately check w/y drivers. Problem is that the 
OutputShort check did very little checking on these nodes. It didn't even do the checking 
as described in the signame docuement where the numbers on w and y must match. 
According to the signame docuement, your are not supposed to be able to short tail_vwy and 
tail_vw since the second one doesn't have the same number of y's as the other signal. 

The rwl lines are a different case. Problem is that some people use w/y to get csyn to 
perform no checking on the interconnected nodes . 

This probably isn't a good idea since we have already have an 'x' 

(promiscuous) for this purpose. I have implemented the following OutputShort checks. As 
from the csyn. rules file: 

# If any driver pin has a w and/or y qualifier, then all driver pins must have # the same 
numbered w and/or y. A cell property can override this. 

# Name mapping from csyn. signames may also change pin properties. 

# Run signame to see what signals get mapped to. 
# 

# Most of the following tests are implemented in code for efficiency: 

# if any driver has a: then 

# w w must match all other drivers . 

# #w #w must match all other drivers. 

# y y must match all other drivers. 

# #y #y must match all other drivers. 

# w|#w #p must match for all drivers. 

Some kind of check needs to be added to allow vref * s to pass too. 

Changing signal names may seem irritating, but we need to perform some kinds of checks to 
make sure our designs are connected properly. 

Your suggested for improvements are appreciated, Fred. 
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From: wayne (Wayne Freitas) 

Sent: Monday, February 13, 1995 12:51 PM 

To: 'graham' 

Cc: 'dane'; 'for 1 ; 'noel' 

Subject: Re: Hold-up time 

> 

> I made a mistake in the arithmetic when we discussed 

> hold-up time of the PSU in my office. 

> 

> 470uF with 1 amp drawn and a droop of 30V results in 

> about 15 milliseconds. If the spec is 32mS, the capacitance 

> is not adequate. 

> 

> I suspect that Noel calculated this earlier using a more 

> optimistic droop, >30 volts. 

> 

> Graham. 

> 

Graham, this is what I have. 

The spec says that we must run on a AC Voltage of 120 VAC +/- 
20% at a frquency of 57 to 63Hz. 


Using the following equation you get a DC voltage out 
of the AC-DC board of: 

Voavg = [(sqrt2 * Vin) *2] - Vf 
Vo = Output Voltage 
Vin = Input Voltage (AC) 
Vf = Internal Voltage drop (~ Svolts) 

— Average — 
Vin - 120 VAC 

Voavg = (sqrt2 * 120) *2 -5 = 334.4Volts DC. 

— Worst Case — 
Vin = 96V AC 

Voavg = (sqrt2 * 96) *2 -5 = 266.5Volts DC. 

The below equation comes from a power supply manufacturer for 
calculating minimum capacitance value for hold-up time. 

Co(eff) = 2 * Pin * Th 

[(Vo - Vp-p) A 2 - (Vdo) A 2] 

Co(eff) = Total effective capacitance value 
Pin = Total system input power requirements 

Vo = DC output rectified unregulated voltage 
Vp-p = Ripple voltage 
Vdo = Dropout voltage of DC module 

Th = Output hold time 


Exhibit Cll 


Page 264 of 559 


If I assume Euterpe uses 28A @ 3.3V, and Calliope uses 17A 
at 3.3V you get 45A @ 3.3V. I don't have all the numbers so 
I won't add anything on for the SDRAM' s or FlashROM, etc. 
In addition we have a 3 A rating for the +5 and a total of 3 A 
rated for the +12 (reg & unreg). The RO spec's 240V minimum 
(Vdo). I've seen the spec on two different vendors for ripple 
voltage around 25V, but I'll be aggresive and use 40V. So if 
we use the above equation I get the following: 

Example 1 Pin = 45A @ 3.3V, 1 A @ 5.0V and 1A @12V =165.5W 
using a 73% effiency rating for the DC 
DC Module requires 227W. 

Example 2 Pin = 45A & 3.3V, 3A @ 5.0V and 3A @12V =200W 
using the same effiency rating would 
then require 274W. This is close to worst 
case condition. 

2 * 227*. 032 14.528 

= = 500uF 

(334.4 - 40) A 2 - (240) A 2 86,671 - 57,600 


2 * 274 * .032 17.536 

= = 24,280uF 

(266.5 - 25) A 2 - (240) A 2 58,322 - 57,600 


Exhibit Cll 


Page 265 of 559 


From: lisar (Lisa Robinson) 

Sent: Monday, February 13, 1995 1:42 PM 

To: 'craig'; 'lisar' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Mori Feb 13 11:41:54 PST 1995 

Copy number: 2 86 

Copy registered to: Vil Bahadur 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore . macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore . ps 

Printed to: rsh plotter lpr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: vanthof (vant) 

Sent: Monday, February 13, 1995 2:24 PM 

To: 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'hopper (Mark Hofmann)'; 'geert (Geert 

Rosseel)'; Vo (Tom Vo)' 
Cc: 'vanthof (Dave Van't Hof)' 

Subject: euterpe still has shorts. 


Euterpe still has a vdd/vss short. I'll start up quadrant short checks again. 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-810 0 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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Subject: 


Sent: 
To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Monday, February 13, 1995 3:19 PM 

'Richard Dickson' 

'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; Vant'; 'torn (Thomas Laidig)' 
Re: gards flow 


Richard Dickson writes: 


you' all, 


this has happened in the past to me and i'm not 
understanding this. 


[snip] 


what happened before 20:52 that caused this job to do this route ??? 

the log file is dickson/euterpe/verilog/bsrc/mc/aaa 

maybe this is why my jobs are failing, i bet the makefiles recipes 
dont survive this backtraking. the job is still running 
but i bet it fails . . . 

I don't think I understand it either. 

It looks like the iter stage is reached, timing fails (exit code 1) and then the make goe 
sback to pass3 and then onto iter a second time. I'm not sure what it will do this time 
(aaa is still growing) . I thought that it should not go back to pass3 , but stay in iter. 
So I'm confused, too. 

Tom or Dave care to have a look at -dickson/euterpe/verilog/bsrc/mc/aaa? 


-hopper 
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Sent: 
To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 

Monday, February 13, 1995 3:23 PM 

'Geert Rosseel' 

'dickson (Richard Dickson)'; 'tbr (Tim B. Robinson)'; 'wampler (Kurt Wampler)' 
Re: Not so good top-level experiment 


Geert Rosseel writes: 
Hi, 

My route of the "better" top-level route finished. It is about 
the same as before +- 5000 unroutes but : 

a. Somehow I don't seem to have the pin-protect turned on. There 
are a lot of places (especially in Cerberus) where a m3 wire 
runs over a ra2 target and obstructs it. This causes a lot of 
disconnects . 

You find no messages of the sort : 

PIN PROTECTORS WILL BE ENFORCED UNTIL ENTIRE NET IS ROUTED ? 

b. gt placement now is bad . . about a zillion unroutes. 

I think the stuff I did helped, but it's hard to tell because 
a lot of wires also interface with gt . . 

I will rebuild the old gt tonight . . if someone can tell 

me soon how to deal with the pin-protect stuff. I can start up another route 
tonight . 

Geert, 

You can find the old gt as: 

~hopper/chip/euterpe/verilog/bsrc/gt/old/gt_control .piml 


-hopper 
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From: lisar (Lisa Robinson) 

Sent: Monday, February 13, 1995 3:51 PM 

To: 'craig'; 'lisar* 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Mon Feb 13 13:50:49 PST 1995 

Copy number: 28 7 

Copy registered to: Bob Venticinque 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore .macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter lpr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 


Exhibit Cll 


Page 270 of 559 


From: Curtis Abbott [abbott@tallis] 

Sent: Monday, February 13, 1995 4:34 PM 

To: 'tbr@tallis'; 'craig@tallis'; 'qua@tallis' 

Subject: averaging instructions 


Recently, our ongoing work has convinced me that we've missed something fairly important 
in the implemented Euterpe instruction set . 

There is a small family of group instructions related to averaging that I think we should 
add at the first opportunity. I suggest 4 instructions, which I'll call g . add. half . N, 
g. sub. half .N, g. add. half .re. N, and g . sub . half . re . N, for N=8 , 16 , 32 , 64 . (Though only 
N=8,16 are critical.) 

The reason to bring this up now is that I've only recently become convinced about this, 
and have become concerned about when the next window of opportunity might be, given the 
directive to make Cronus "identical" in uArch to Euterpe. The reason to bring it up 
"privately" is that I think this is rightly a sensitive subject -- Euterpe is frozen, and 
needs to be completed. However, if we judge the benefit of adding these to outweigh the 
cost, I don't want it not to happen because nobody spoke up. 

Henry and Craig have both suggested these or similar instructions in the past, but they 
did not find sufficiently vocal champions at the time. 

In particular, Craig suggested (in a microarchitecture meeting on Feb 11, 1994): 

g . add3 . half , N : d = (a + b + c) » 1 
with one idea being to set c to 1 or 0 for rounding. 

Henry's suggestions have occurred in meetings and private communications; I don't have 

specific notes. He suggests (and I 

concur) 

g . add. half .N: c = " (a + b) >> 1" over N-bit fields 

g. sub. half .N: c = " (b - a) » 1" over N-bit fields 
These would not require new major opcode points. Henry has also pointed out on several 
occasions that round- to-even is a useful primitive. It works as follows: 

#define SUM_ROUND_TO_EVEN (a, b) (a + b + ( ( (a + b) >> 1) & 1) ) D I FF_ROUND_TO_E VEN 
would be similar. (I believe this definition is only correct if you're about to shift out 
the LSB . ) The corresponding instructions would be 

g. add. half .re. N: c = " SUM_ROUND_TO_EVEN ( a , b) » 1" over N-bit 

fields 

g. sub. half .re.N: c = "DIFF_ROUND_TO_EVEN(b, a) >> 1" over N-bit 

fields 

The basic intuition about round- to-even is that it "atomically" 

corrects the statistical bias introduced by using a right shift to divide by powers of 2. 
The alternative is sometimes adding 1 and sometimes adding 0, so that you're biasing 
sometimes too high, sometimes too low. This, as well as other tricks, can be made to 
work, but has two disadvantages: (1) much harder to think about and program correctly; (2) 
is typically sensitive to pattern noise, i.e., since the rounding is done differently on 
different data, certain input patterns will come out wrong. 

One way to think about (a+b) >>1 is as follows. The group add and sub operations that we 
have don't allow for full precision operands without overflow. E.g. an 8 -bit add or sub 
generates 9 bits of result; our current instructions take the low order 8 of these; the 
suggested new instructions would take the high order 8 of them. The basic reason this is 
good is that it allows us to use full precision fields (e.g. 8 -bit fields) without 
expansion in many cases. 


The points that need to be addressed are: 

1. do these instructions require a significant number of existing terp instructions to 
emulate? 

2. what would be the difficulty of adding (some or all of) these instructions to the 
design we have? 

3. how would we use these instructions, and what kind of savings could we expect? 
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As to emulation with existing instructions: g. add. half .N or g.sub.half.N require 8 
instructions to emulate; the round-to-even versions require 14. It is relatively rare 
that we would actually emulate these instructions given their costs, though I have done 
it. 

More commonly, we would expand once and work in the expanded space, making the real cost 
less than a factor of 8 greater. 

As to design difficulty: it looks like the g . {add, sub} . half . N would require relatively 
little change to the ES unit since the bits are already being computed. The round- to -even 
versions would require in addition that bit 1 of the output be added to bit 0 of the sum; 
this introduces an opportunity for another carry propagate, so it is clearly more complex. 
I'm not competent to say more. 

As to uses of these instructions, they would include summations in video coding 
calculations, comb filtering for decimation and interpolation in high rate signal 
processing, intermediate combining stages in fft's and so on. More specifically... 

In the MPEG- 2 decode macroblock reconstruction, gaddhalfre8 would remove at least 160 (of 
about 640) instructions from the inner loop in the uni- directional case, and similarly for 
the bi-directional case. 

This is a potential 25% speedup, much, but not all, of which could be obtained with 
gaddhalf8 as well. The overall speedup would be less relative to the fully burdened loop, 
and our memory system may be the real bottleneck at the moment, but. . . 

In the video encoding areas, the potential customers with whom we have interacted have 
been interested in mean squared error over square blocks of various sizes. g.sub.half.N 
is applicable to this computation, since otherwise the difference isn't computable without 
overflow. For example, in computing mean squared error between two 

8x8 blocks of already loaded bytes, using a gsubhalf8 instruction leads to a 50% cycle 
count savings, from 52 to 2 6 cycles. 

(I note in passing that we have recently developed an approach to searching for minimum 
mean squared error across a range of blocks that uses fft's instead of direct computations 
and is still more efficient. 

However, it probably does not replace all uses of summation over 2-d 
blocks . ) 

The situation is similar for the absolute value norm {sum of absolute value of 
differences), which is used at least in some hardware in the literature. For a 16x16 
block of already loaded bytes, using 

gaddhalf8 (or better still, gaddhalfre8) in the summation stages takes the computation 

from 128 to 80 cycles. (I note in passing that a 

gabsdiff8 instruction would reduce it by a further 48 cycles.) 

In the filtering area, Henry likes the following FIR filter: 

y[n] = (x[n-2] + 2*x[n-l] + x [n] ) /4 
abbreviated as (1, 2, 1) . This lowpass filter has relatively little droop at DC and 
relatively good rejection near Nyquist. Cascaded with itself, these properties are 
amplified, since it has a cos A 2 shaped transfer function. The cascaded version could be 
used in QAM timing recovery, which operates on 20M points/sec. With gaddhalf8 (or 
gaddhalfreS) , the (1, 2, 1) filter takes 4 instructions (plus edge 

costs) for 16 samples, or 0.25 cycles/point. The alternative with expanding and such takes 
10, or 0.625 cycles/point. 

Interestingly, applying the (1, 2, 1) filter to a signal shuffled with 0's creates a 2x 
linear interpolating upsampler, so speeding it up appears to have broad utility. This 
trick can be cascaded for 4x, 8x, and so on. 

It seems clear that various other comb filters can be handled in fewer instructions with 
g. add. half primitives, and even if we eventually have a single cycle multiplier, these 
inherently double the throughput by not widening the result . 


In summary, there seem to be a number of important, inner loop computations for which 
these instructions speed things significantly, sometimes by more than a factor of 2, and 
at least the non- rounding versions appear to be easy to implement. 

- Curtis 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisar (Lisa Robinson) 

Monday, February 13, 1995 6:06 PM 

'mws'; 'woody' 

'dickson'; 'billz'; 'tbr'; 'jeffm' 

sysproto 


Well sysprotol ran okay it just took a little longer to run. 

Sysproto2 however looks like it may have taken a machine check. 
The trace file is on rhodan /s3 

/s3/euterpe/verilog/bsrc/res/13295 . 2997/results/sysproto2_l . dpo 
I'll run it in verilog. 


Lisa R. 
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From: Gregg Kellogg [gregg@hts.microunity.com] 

Sent: Monday, February 13, 1995 6:54 PM 

To: 'mediacom-software' 

Subject: onchip memory accounting 


Here's some accounting of on-chip 
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memory usage by object file: 

3648 BSS ukernel /dev /video- out . o 
0 BSS ukernel/dev/ cable -in. o 
0 BSS lib/dlws/terp/terp_display.o 

2512 BSS ukernel/dev/mpeg2-in. o 

1872 BSS ukernel/dev/ ir-cmds- in. o 
0 BSS ukernel/kern/oc_kstack. o 

1808 BSS ukernel/dev/ir-in. o 
368 BSS ukernel /dev /audio- out . o 

1424 BSS ukernel/ dev/ ir- out . o 

0 BSS ukernel/kern/cxtswitch. o 
0 BSS ukernel/sched/edf . o 
0 BSS ukerne 1 /kern/ thread. o 

3 2 BSS lib/f ec/rs_proc_blk_k.o 
24 BSS ukernel/kern/clock.o 

0 BSS ukernel /dev/oc_space . o 
760 BSS lib/dlws/terp/init .o 

4 0 BSS ukernel /kern/ sched.o 
368 BSS ukernel /dev/ tv- in. o 

64 BSS ukernel /dev/dev- host .o 
0 BSS lib/fec/log__tblJc.o 
0 BSS lib/fec/inverse_tbl_k.o 
0 BSS lib/fec/expon_tbl_k.o 
0 BSS ukernel / kern / oc_space . o 
112 BSS ukerne 1/ kern / devi ce .o 
0 BSS lib/dlws/terp/dl.o 
0 BSS lib/f ec/rs_syndrome_k.o 
0 BSS lib/f ec/extra_vec_k.o 
0 BSS lib/f ec/genpoly_k.o 

16 BSS ukernel/kern/task.o 
13048 BSS Total 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: lisar (Lisa Robinson) 

Sent: Monday, February 13, 1995 9:13 PM 

To: 'mws' 

Subject: Re: sysproto 


/n/rhodan/s3/euterpe/verilog/bsrc/res/13295 . 2997/results/sysproto2_l . dpo 
Lisa R. 


Exhibit Cll 


Page 275 of 559 


From: lisar (Lisa Robinson) 

Sent: Monday, February 13, 1995 9:36 PM 

To: 'sysadm' 

Cc: 'mws' 

Subject: Re: sysproto 

I'm not sure. Maybe it is just not visible from the machine you 
are using. I know we have had problems with this partition not being 
visible, infact at one point I had thought that it wasn't being 
exported. 

Lisa R. 


Begin Included Message 

>From mws Mon Feb 13 19:34:07 1995 
Return-Path: <mws> 

Received: from clytemnestra.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA23086; Mon, 13 Feb 95 19:34:04 PST 
Received: from localhost by clytemnestra.microunity.com (8.6.4/muse-sw.3) 

idTAA20166; Mon, 13 Feb 1995 19:33:51 -0800 
From: mws (Mark Semmelmeyer) 

Message-Id: <199502140333.TAA20166@clytemnestra.microunity.com> 
Subject: Re: sysproto 

To: lisar@MicroUnity.com (Lisa Robinson) 
Date: Mon, 13 Feb 95 19:33:48 PST 

In-Reply-To: <199502140313.TAA13136@nosferatu.microunity.com>; from "Lisa Robinson" at Feb 13, 95 7:13 pm 
X-Mailer: ELM [version 2.3 PL1 1 ] 
Content-Length: 410 
X-Lines: 12 
Status: RO 

> 

> /n/rhodan/s3/euterpe/verilog/bsrc/res/l 3295.2997/results/sysproto2_l .dpo 

> 

> Lisa R. 

> 

Hmmm. The res directory is a soft link: 

mws clytemnestra(7):/n/rhodan/s3/euterpe> Is -1 !$ 
Is -1 verilog/bsrc/res 

lrwxrwxrwx 1 lisar 7 Jan 26 16:42 verilogftsrc/res -> /s2/res 
not visible unless I am logged onto rhodan. I wonder if this is one 
of those file system weirdnesses or expected. 


End Included Message 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Monday, February 13, 1995 11:00 PM 
'geert'; 'hopper'; 'tbr' 
gards flow 


you ' all, 

this has happened in the past to me and i'm not understanding this. 


gards /mc- iter . mug . rcf . 2 
gards /mc- iter . df f 
gards/garout . cf g 
gards/mc-iter . garout . lis 
gards/mc-iter .netcap 
gards/mc-iter . vrf 
gards/invoke . com 
gards/mc-iter . gil 
gards/maskout . lis 
gards/maskout . cf g 
gards/mc-iter. ly 
gards/mc-iter . obs 
gards /mc - f inal . s t at 
gards /mc- final . topt . log 
gards/mc - iter . pirn 
gards/mc-pass3 .pirn. map 
gards/mc -pass3 .pim.pdl . tmp 
gards/mc-pass3 .pim.c2l 
gards/mc-pass3 . pirn . xrf . tmp 
gards/mc -pas s3 .pirn. warn 
gards/mc- pa ss3 .pim.pif 
gards/mc-pass3 . pirn . pif . warn 
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before 20 

52 that 
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this job to do this route ??? 


the log file is dickson/ euterpe/verilog/bsrc/mc/aaa 

maybe this is why my jobs are failing, i bet the makefiles recipes dont survive this 
backtraking. the job is still running but i bet it fails . . . 


dickson 
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From: 


tbr 


To: 


Sent: 


Subject: 


Monday, February 13, 1995 11:06 PM 
'dickson'; 'mws' 

forwarded message from Curtis Abbott 


Follow Up Flag: Follow up 
Flag Status: Red 

Some background on the average instruction . . . 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["7343" "Mon" "13" "February" "95" "14:34:27" "-0800" "Curtis Abbott" "abbott@tallis " nil "145" "averaging 
instructions" " A From:" nil nil "2"]) 
Return-Path: <abbott@tallis> 

Received: from tallis (tallis.microunity.com) by gaea.microunity.com (4.1/musel.3) 

id AA04060; Mon, 13 Feb 95 14:34:09 PST 
Received: by tallis (931 1 10.SGI.ANONFTP/920502.SGI) 

fortbr@gaea.microunity.com id AA09688; Mon, 13 Feb 95 14:34:27 -0800 
Message-Id: <9502132234.AA09688@tallis> 
From: abbott@tallis (Curtis Abbott) 
To: tbr@tallis, craig@tallis, qua@tallis 
Subject: averaging instructions 
Date: Mon, 13 Feb 95 14:34:27 -0800 

Recently, our ongoing work has convinced me that we've missed 
something fairly important in the implemented Euterpe instruction set. 
There is a small family of group instructions related to averaging 
that I think we should add at the first opportunity. I suggest 4 
instructions, which I'll call g.add.half.N, g.sub.half.N, 
g.add.half.re.N, and g.sub.half.re.N, for N=8, 16,32,64. (Though only 
N=8,16 are critical.) 

The reason to bring this up now is that I've only recently become 
convinced about this, and have become concerned about when the next 
window of opportunity might be, given the directive to make Cronus 
"identical" in uArch to Euterpe. The reason to bring it up 
"privately" is that I think this is rightly a sensitive subject - 
Euterpe is frozen, and needs to be completed. However, if we judge 
the benefit of adding these to outweigh the cost, I don't want it not 
to happen because nobody spoke up. 

Henry and Craig have both suggested these or similar instructions in 
the past, but they did not find sufficiently vocal champions at the 
time. 

In particular, Craig suggested (in a microarchitecture meeting on Feb 
11, 1994): 

g.add3.half.N: d = (a + b + c) » 1 
with one idea being to set c to 1 or 0 for rounding. 

Henry's suggestions have occurred in meetings and private 
communications; I don't have specific notes. He suggests (and I 
concur) 

g.add.half.N: c = "(a + b) » 1 " over N-bit fields 


Exhibit Cll 


Page 278 of 559 


g.sub.half.N: c = "(b - a) » 1 " over N-bit fields 
These would not require new major opcode points. Henry has also 
pointed out on several occasions that round-to-even is a useful 
primitive. It works as follows: 

#defme SUM_ROUND_TO_EVEN(a, b) (a + b + (((a + b) » 1) & 1)) 
DIFF_ROUND_TO_EVEN would be similar. (I believe this definition is 
only correct if you're about to shift out the LSB.) The corresponding 
instructions would be 

g.add.half.re.N: c = "SUM_ROUND_TO_EVEN(a, b) » I " over N-bit fields 

g.sub.half. re.N: c - "DIFF_ROUND_TO_EVEN(b, a) » 1 " over N-bit fields 

The basic intuition about round-to-even is that it "atomically" 
corrects the statistical bias introduced by using a right shift to 
divide by powers of 2. The alternative is sometimes adding 1 and 
sometimes adding 0, so that you're biasing sometimes too high, 
sometimes too low. This, as well as other tricks, can be made to 
work, but has two disadvantages: (1) much harder to think about and 
program correctly; (2) is typically sensitive to pattern noise, i.e., 
since the rounding is done differently on different data, certain 
input patterns will come out wrong. 

One way to think about (a+b)»l is as follows. The group add and sub 
operations that we have don't allow for full precision operands 
without overflow. E.g. an 8-bit add or sub generates 9 bits of 
result; our current instructions take the low order 8 of these; the 
suggested new instructions would take the high order 8 of them. The 
basic reason this is good is that it allows us to use full precision 
fields (e.g. 8-bit fields) without expansion in many cases. 


The points that need to be addressed are: 

1 . do these instructions require a significant number of existing terp 
instructions to emulate? 

2. what would be the difficulty of adding (some or all of) these 
instructions to the design we have? 

3. how would we use these instructions, and what kind of savings could 
we expect? 

As to emulation with existing instructions: g.add.half.N or 
g.sub.half.N require 8 instructions to emulate; the round-to-even 
versions require 14. It is relatively rare that we would actually 
emulate these instructions given their costs, though I have done it. 
More commonly, we would expand once and work in the expanded space, 
making the real cost less than a factor of 8 greater. 

As to design difficulty: it looks like the g.{add,sub}.half.N 
would require relatively little change to the ES unit since the 
bits are already being computed. The round-to-even versions would 
require in addition that bit 1 of the output be added to bit 0 of the 
sum; this introduces an opportunity for another carry propagate, so it 
is clearly more complex. I'm not competent to say more. 

As to uses of these instructions, they would include summations in 
video coding calculations, comb filtering for decimation and 
interpolation in high rate signal processing, intermediate combining 
stages in fft's and so on. More specifically... 

In the MPEG-2 decode macroblock reconstruction, gaddhalfre8 would 
remove at least 160 (of about 640) instructions from the inner loop in 
the uni -directional case, and similarly for the bi-directional case. 
This is a potential 25% speedup, much, but not all, of which could be 
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obtained with gaddhalfS as well. The overall speedup would be less 
relative to the fully burdened loop, and our memory system may be the 
real bottleneck at the moment, but... 

In the video encoding areas, the potential customers with whom we have 
interacted have been interested in mean squared error over square 
blocks of various sizes. g.sub.half.N is applicable to this 
computation, since otherwise the difference isn't computable without 
overflow. For example, in computing mean squared error between two 
8x8 blocks of already loaded bytes, using a gsubhalfS instruction 
leads to a 50% cycle count savings, from 52 to 26 cycles. 

(1 note in passing that we have recently developed an approach to 
searching for minimum mean squared error across a range of blocks that 
uses fft's instead of direct computations and is still more efficient. 
However, it probably does not replace all uses of summation over 2-d 
blocks.) 

The situation is similar for the absolute value norm (sum of absolute 
value of differences), which is used at least in some hardware in the 
literature. For a 16x16 block of already loaded bytes, using 
gaddhalfS (or better still, gaddhalfre8) in the summation stages takes 
the computation from 1 28 to 80 cycles. (I note in passing that a 
gabsdiffg instruction would reduce it by a further 48 cycles.) 

In the filtering area, Henry likes the following FIR filter: 

y[n] - (x[n-2] + 2*x[n-l] + x[n])/4 
abbreviated as (1, 2, 1). This lowpass filter has relatively little 
droop at DC and relatively good rejection near Nyquist. Cascaded with 
itself, these properties are amplified, since it has a cos A 2 shaped 
transfer function. The cascaded version could be used in QAM timing 
recovery, which operates on 20M points/sec. With gaddhalfS (or 
gaddhalfre8), the (1, 2, 1) filter takes 4 instructions (plus edge 
costs) for 16 samples, or 0.25 cycles/point. The alternative with 
expanding and such takes 10, or 0.625 cycles/point. 

Interestingly, applying the (1 , 2, 1) filter to a signal shuffled with 
O's creates a 2x linear interpolating upsampler, so speeding it up 
appears to have broad utility. This trick can be cascaded for 4x, 8x, 
and so on. 

It seems clear that various other comb filters can be handled in fewer 
instructions with g.add.half primitives, and even if we eventually 
have a single cycle multiplier, these inherently double the throughput 
by not widening the result. 


In summary, there seem to be a number of important, inner loop 
computations for which these instructions speed things significantly, 
sometimes by more than a factor of 2, and at least the non-rounding 
versions appear to be easy to implement. 

- - Curtis 

End of forwarded message 
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From: tbr (Tim B. Robinson) 

Sent: Monday, February 1 3, 1 995 1 1 :06 PM 

To: 'dickson'; 'mws' 

Subject: forwarded message from Curtis Abbott 


Some background on the average instruction . . . 

Start of forwarded message 

Status : RO 

X-VM-v5-Data : {[nil nil nil nil nil nil nil nil nil] 

["7343" "Mon" "13" "February" "95" "14:34:27" "-0800" "Curtis Abbott" "abbott@tallis 
" nil "145" "averaging instructions" " A From:" nil nil "2"]) 
Return-Path: <abbott@tallis> 

Received: from tallis (tallis.microunity.com) by gaea.microunity.com 
(4.1/musel.3) 

id AA04060; Mon, 13 Feb 95 14:34:09 PST 
Received: by tallis (931110 .SGI. ANONFTP/920502 . SGI) 

for tbr@gaea.microunity.com id AA0968 8; Mon, 13 Feb 95 14:34:27 -0800 
Message-Id: <9502132234 . AA09688@tallis> 
From: abbot t@tallis (Curtis Abbott) 
To: tbrotallis, craigOtallis, gua@tallis 
Subject: averaging instructions 
Date: Mon, 13 Feb 95 14:34:27 -0800 

Recently, our ongoing work has convinced me that we've missed something fairly important 
in the implemented Euterpe instruction set . 

There is a small family of group instructions related to averaging that I think we should 
add at the first opportunity. I suggest 4 instructions, which I'll call g. add. half .N, 
g. sub. half .N, g .add. half . re .N, and g. sub. half .re. N, f or N=8 , 16 , 32 , 64 . (Though only 
N=8,16 are critical.) 

The reason to bring this up now is that I've only recently become convinced about this, 
and have become concerned about when the next window of opportunity might be, given the 
directive to make Cronus "identical" in uArch to Euterpe. The reason to bring it up 
"privately" is that I think this is rightly a sensitive subject Euterpe is frozen, and 
needs to be completed. However, if we judge the benefit of adding these to outweigh the 
cost, I don't want it not to happen because nobody spoke up. 

Henry and Craig have both suggested these or similar instructions in the past, but they 
did not find sufficiently vocal champions at the time. 

In particular, Craig suggested (in a microarchitecture meeting on Feb 11, 1994) : 

g . add3 . half . N : d = (a + b + c) » 1 
with one idea being to set c to 1 or 0 for rounding. 

Henry's suggestions have occurred in meetings and private communications; I don't have 

specific notes. He suggests (and I 

concur) 

g. add. half ,N: c = " (a + b) >> 1" over N-bit fields 

g. sub. half .N: c = " (b - a) >> 1" over N-bit fields 
These would not require new major opcode points. Henry has also pointed out on several 
occasions that round-to-even is a useful primitive. It works as follows: 

#define sum_round_to_even (a, b) (a + b + ( ( (a + b) » D & D) diff_round_to_even 
would be similar. (I believe this definition is only correct if you're about to shift out 
the LSB . ) The corresponding instructions would be 

g. add. half .re. N: c = "SUM_ROUND_TO_EVEN (a, b) >> 1" over N-bit 

fields 

g. sub. half .re.N: c = "DIFF_R0UND_T0_EVEN (b, a) » 1" over N-bit 

fields 

The basic intuition about round- to -even is that it "atomically " 

corrects the statistical bias introduced by using a right shift to divide by powers of 2 . 
The alternative is sometimes adding 1 and sometimes adding 0, so that you're biasing 
sometimes too high, sometimes too low. This, as well as other tricks, can be made to 
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work, but has two disadvantages: (1) much harder to think about and program correctly; (2) 
is typically sensitive to pattern noise, i.e., since the rounding is done differently on 
different data, certain input patterns will come out wrong. 

One way to think about (a+b)>>l is as follows. The group add and sub operations that we 
have don't allow for full precision operands without overflow. E.g. an 8-bit add or sub 
generates 9 bits of result; our current instructions take the low order 8 of these; the 
suggested new instructions would take the high order 8 of them. The basic reason this is 
good is that it allows us to use full precision fields (e.g. 8-bit fields) without 
expansion in many cases. 


The points that need to be addressed are: 

1. do these instructions require a significant number of existing terp instructions to 
emulate? 

2. what would be the difficulty of adding (some or all of) these instructions to the 
design we have? 

3. how would we use these instructions, and what kind of savings could we expect? 

As to emulation with existing instructions: g . add. half . N or g. sub. half ,N require 8 
instructions to emulate; the round-to-even versions require 14. It is relatively rare 
that we would actually emulate these instructions given their costs, though I have done 
it. 

More commonly, we would expand once and work in the expanded space, making the real cost 
less than a factor of 8 greater. 

As to design difficulty: it looks like the g. {add, sub} .half .N would require relatively 
little change to the ES unit since the bits are already being computed. The round- to- even 
versions would require in addition that bit 1 of the output be added to bit 0 of the sum; 
this introduces an opportunity for another carry propagate, so it is clearly more complex. 
I ■ m not competent to say more . 

As to uses of these instructions, they would include summations in video coding 
calculations, comb filtering for decimation and interpolation in high rate signal 
processing, intermediate combining stages in f f t ■ s and so on. More specifically... 

In the MPEG-2 decode macroblock reconstruction, gaddhalfre8 would remove at least 160 (of 
about 640) instructions from the inner loop in the uni-directional case, and similarly for 
the bi-directional case. 

This is a potential 25% speedup, much, but not all, of which could be obtained with 
gaddhalf8 as well. The overall speedup would be less relative to the fully burdened loop, 
and our memory system may be the real bottleneck at the moment, but. .. 

In the video encoding areas, the potential customers with whom we have interacted have 
been interested in mean squared error over square blocks of various sizes. g. sub. half ,N 
is applicable to this computation, since otherwise the difference isn't computable without 
overflow. For example, in computing mean squared error between two 

8x8 blocks of already loaded bytes, using a gsubhalf8 instruction leads to a 50% cycle 
count savings, from 52 to 2 6 cycles. 

(I note in passing that we have recently developed an approach to searching for minimum 
mean squared error across a range of blocks that uses fft's instead of direct computations 
and is still more efficient. 

However, it probably does not replace all uses of summation over 2-d 
blocks . ) 

The situation is similar for the absolute value norm (sum of absolute value of 
differences), which is used at least in some hardware in the literature. For a 16x16 
block of already loaded bytes, using 

gaddhalf8 (or better still, gaddhalfre8) in the summation stages takes the computation 

from 128 to 80 cycles. (I note in passing that a 

gabsdiffS instruction would reduce it by a further 48 cycles.) 

In the filtering area, Henry likes the following FIR filter: 

y[n] m (x[n-2j + 2*x[n-l] + x [n] ) /4 
abbreviated as (1, 2, 1) . This lowpass filter has relatively little droop at DC and 
relatively good rejection near Nyquist. Cascaded with itself, these properties are 
amplified, since it has a cos A 2 shaped transfer function. The cascaded version could be 
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used in QAM timing recovery, which operates on 20M points/sec. With gaddhalf8 (or 
gaddhalfre8) , the (1, 2, 1) filter takes 4 instructions (plus edge 

costs) for 16 samples, or 0.25 cycles/point. The alternative with expanding and such takes 
10, or 0.625 cycles/point. 

Interestingly, applying the (1, 2, 1) filter to a signal shuffled with O's creates a 2x 
linear interpolating upsampler, so speeding it up appears to have broad utility. This 
trick can be cascaded for 4x, 8x, and so on. 

It seems clear that various other comb filters can be handled in fewer instructions with 
g. add. half primitives, and even if we eventually have a single cycle multiplier, these 
inherently double the throughput by not widening the result. 


In summary, there seem to be a number of important, inner loop computations for which 
these instructions speed things significantly, sometimes by more than a factor of 2, and 
at least the non- rounding versions appear to be easy to implement. 

- - Curtis 

End of forwarded message 
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Subject: 


Sent: 

To: 

Cc: 


From: 


geert (Geert Rosseel) 

Monday, February 13, 1995 11:28 PM 

'geert@tomato.microunity.com'; 'hopper' 

'dickson'; 'tor'; 'wampler' 

Re: Not so good top-level experiment 


> You find no messages of the sort: 

> PIN PROTECTORS WILL BE ENFORCED UNTIL ENTIRE NET IS ROUTED 

Well actually . . I do . . There is one message like this at the beginning of my routing 
strategy ( /n/ghidra/s3 /geert /euterpe/verilog/bsrc/route . out 
) 

However, when I look at the result in redit, it doesn seem to have worked 


Don't I have to run gasavepins somehow before I route and if so, where does that happen ? 


Geert 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, February 14, 1995 12:23 AM 

To: Tom Laidig (tau)' 

Cc: 'hopper@MicroUnity.com*; 'dickson (Richard Dickson)'; 'tbr (Tim B. Robinson)'; 'Geert Rosseel'; 
'vant 1 ; 'tau' 

Subject: Re: gards flow 

Tom Laidig (tau) writes: 
J I don't think I understand it either. 

jit looks like the iter stage is reached, timing fails (exit code 1) and 
(then the make goe sback to pass3 and then onto iter a second time. I'm 
| not sure what it will do this time (aaa is still growing). I thought that 
jit should not go back to pass3, but stay in iter. So I'm confused, too. 
JTom or Dave care to have a look at ~dickson/euterpe/verilog/bsrc/mc/aaa? 

Duh. I understand this Makefile about as much as I understand 
neurobiology, but the above description doesn't seem to jibe with what I 
see. It looks to me as if it goes pass2, pass3, pass2, iter, iter... 

[snip] 

Okay. I may have got someting caught in the bifocals (as solo used to say) 
However, is that the behavior we expect? I thought we should see: 
passl pass2 pass3 iter*n 

-hopper 
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From: torn (Tom Laidig (tau)) 
Sent: Tuesday, February 14, 1995 8:19 AM 
To: 'Mark Hermann' 

Cc: 'dickson (Richard Dickson)'; 'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)'; 'vant'; 'tau' 
Subject: Re: gards flow 

Mark Hofmann writes: 
|Richard Dickson writes: 
| you 'all, 

j this has happened in the past to me and i'm not 
j understanding this. 

I [snip] 

| what happened before 20:52 that caused this job to do this route ??? 

j the log file is dickson/euterpe/verilog/bsrc/mc/aaa 

j maybe this is why my jobs are failing, i bet the makefiles recipes 
j dont survive this backtraking. the job is still running 
j but i bet it fails ... 

jl don't think I understand it either. 

|It looks like the iter stage is reached, timing fails (exit code 1) and 
jthen the make goe sback to pass3 and then onto iter a second time. I'm 
jnot sure what it will do this time (aaa is still growing). I thought that 
jit should not go back to pass3, but stay in iter. So I'm confused, too. 
|Tom or Dave care to have a look at ~dickson/euterpe/verilog/bsrc/mc/aaa? 

Duh. I understand this Makefile about as much as I understand 
neurobiology, but the above description doesn't seem to jibe with what I 
see. It looks to me as if it goes pass2, pass3, pass2, iter, iter... 

grep '###GAROUT' ~dickson/euterpe/verilogftsrc/mc/aaa 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass2 
protectpins 2 -strategy mc-pass2.mug.rcf.l -congval mc-pass2.mug.cvp. 1 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass2 
protectpins 2 -strategy mc-pass2.mug.rcf.2 -congval mc-pass2.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass2 
protectpins 2 -strategy mc-pass2.mug.rcf. 1 -congval mc-pass2.mug.cvp.l 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass2 
protectpins 2 -strategy mc-pass2.mug.rcf.2 -congval mc-pass2.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass3 
protectpins 2 -strategy mc-pass3.mug.rcf.l -congval mc-pass3.mug.cvp.l 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass3 
protectpins 2 -strategy mc-pass3.mug.rcf.2 -congval mc-pass3.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass2 
protectpins 2 -strategy mc-pass2.mug.rcf.l -congval mc-pass2.mug.cvp.l 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-pass2 
protectpins 2 -strategy mc-pass2.mug.rcf.2 -congval mc-pass2.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter -listing mc-iter.garout. lis .phase 1 
protectpins 2 -strategy mc-iter.mug.rcf.l -congval mc-iter .mug.cvp.l 


-listing mc-pass2.garout.lis.phasel - 
-listing mc-pass2. garout. lis. phase2 - 
-listing mc-pass2.garout.lis.phasel - 
-listing mc-pass2. garout. lis. phase2 - 
-listing mc-pass3. garout. lis. phase 1 - 
-listing mc-pass3. garout. Iis.phase2 - 
-listing mc-pass2.garout.lis.phasel - 
-listing mc-pass2.garout.lis.phase2 - 
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###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter. mug.rcf. 2 -congval mc-iter.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter.mug.rcf.l -congval mc-iter.mug.cvp. 1 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter. mug.rcf .2 -congval mc-iter.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter.mug.rcf.l -congval mc-iter.mug.cvp. 1 

###GAROUT### /n/rama/s5/dickson/euterpe/too!s/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter.mug.rcf.2 -congval mc-iter.mug.cvp.2 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter. mug.rcf. 1 -congval mc-iter.mug.cvp. 1 

###GAROUT### /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke garout mc-iter 
protectpins 2 -strategy mc-iter.mug.rcf.2 -congval mc-iter.mug.cvp.2 


-listing mc-iter.garout.lis.phase2 - 
-listing mc-iter.garout,lis.phasel - 
-listing mc-iter.garout.lis.phase2 - 
-listing mc-iter.garoutlis.phasel - 
-listing mc-iter.garoutIis.phase2 - 
-listing mc-iter.garoutlis.phasel - 
-listing mc- iter. garout. lis. phase2 - 
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From: vanthof (vant) 

Sent: Tuesday, February 14, 1995 8:43 AM 
To: 'Mark HofmanrV 

Cc: 'dickson (Richard Dickson)'; 'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)'; 'Dave Van't Hof; 
Thomas Laidig' 

Subject: Re: gards flow 

Mark Hofmann writes: 

> 

>Tom Laidig (tau) writes: 

> 1 1 don't think I understand it either. 

> jit looks like the iter stage is reached, timing fails (exit code 1) and 

> jthen the make goe sback to pass3 and then onto iter a second time. I'm 

> jnot sure what it will do this time (aaa is still growing). I thought that 

> jit should not go back to pass3, but stay in iter. So I'm confused, too. 

> |Tom or Dave care to have a look at ~dickson/euterpe/verilog/bsrc/mc/aaa? 
> 

> Duh. I understand this Makefile about as much as I understand 

> neurobiology, but the above description doesn't seem to jibe with what I 

> see. It looks to me as if it goes pass2, pass3, pass2, iter, iter... 

> 

> [snip] 

> 

>Okay. I may have got someting caught in the bifocals (as solo used to say) 
>However, is that the behavior we expect? I thought we should see: 

> passl pass2 pass3 iter*n 

> 

>-hopper 

> 

I understand the makefiles even less than Tom does, but Yes, I thought the 
procedure was as you describe. 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> 
Don't blame me, I didn't vote for him! 


Exhibit Cll 


Page 288 of 559 


From: 
Sent: 


Tuesday, February 14, 1995 9:16 AM 
'hopper (Mark Hofmann)' 
Re: gards flow 


tbr 


To: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Tue Feb 14): 

Tom Laidig (tau) writes: 
|I don't think I understand it either. 

jit looks like the iter stage is reached, timing fails (exit code 1 ) and 
[then the make goe sback to pass3 and then onto iter a second time. I'm 
|not sure what it will do this time (aaa is still growing). I thought that 
jit should not go back to pass3, but stay in iter. So I'm confused, too. 
jTom or Dave care to have a look at ~dickson/euterpe/verilog/bsrc/mc/aaa? 

Duh. I understand this Makefile about as much as I understand 
neurobiology, but the above description doesn't seem to jibe with what I 
see. It looks to me as if it goes pass2, pass3, pass2, iter, iter... 


Okay. I may have got someting caught in the bifocals (as solo used to say) 
However, is that the behavior we expect? I thought we should see: 
passl pass2 pass3 iter*n 

That's what it should do, unless something changes in the mean time 
which causes it to think something is out of date again. However, 
that usually results in apretty complete reset, not just back to pass 
2. For it not to have gone back to pass 1, it must have been 
something associated with the routing step. The difference between 
pass2 ansd passl is that pass I only does a placement and manhattan 
estimate. 

So, is there anything associated with the routing step (eg rcf files 
etc) that could have changed then. I doub't it given rich is using 
the snapshot proteus. 


[snip] 


Tim 


Exhibit Cll 


Page 289 of 559 


Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Tuesday, February 14, 1995 10:22 AM 

'geert'; 'geert@tomato. microunity.com'; 'hopper' 

'dickson'; 'tor' 

Re: Not so good top-level experiment .. 


Hopper queries: 


> You find no messages of the sort : 

> PIN PROTECTORS WILL BE ENFORCED UNTIL ENTIRE NET IS ROUTED 
Geert replies: 


@ Well actually . . I do . . There is one message like this at the beginning @of my routing 
strategy { /n/ghidra/s3 /geert/euterpe/verilog/bsrc/route . out ) @ However, when I look at 
the result in redit, it doesn seem to have worked @ @ Don't I have to run gasavepins 
somehow before I route and if so, ©where does that happen ? 

Pin protectors are only generated for nets with more than 1 pin. The 
function of gasavepins is to generate pin protectors for 1-pin nets, to 
prohibit routing from crossing these target locations when routing a 
sub-block stand-alone. It should not be necessary to run gasavepins 
for the top-level route, since there shouldn't be any one-pin nets that 
we care about protecting at the full-chip level. 

Remember also that the pin protection logic in the current GAROUT is somewhat 
limited. It only protects 1 layer above the target (instead of all layers 
above and below the target; a fix we've been begging for for a couple of 
years now) . So you will see M2 targets covered with unrelated M4 all over 
the place. 

If there is a group of nets that you want "harder" pin protectors 
on, the GEARS program "gaprotarg" will generate actual physical metal 
stubs over the targets of a user-specified list of nets (and can then 
strip out any spurious metal left over after routing is complete) . 
Early 

tests applying "gaprotarg" on all the nets in a design did not show an 
overall improvement in routing completion, but the program may be useful 
if applied sparingly to some of these selected problem areas . 


- Kurt 
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From: brianl (Brian Lee) 

Sent: Tuesday, February 14, 1995 10:47 AM 

To: Tim B. Robinson' 

Cc: 'bpw (B. P. Wong)'; 'vanthof (Dave Van't Hof)'; 'age (Alan Corn/)' 
Subject: Re: Timing model 

Tim B. Robinson writes: 

I 

| We will need an accurate timing model for topt for iobytem, the 
| version of iobyte in mnemosyne. Unlike the euterpe version, this one 
jis designed to be clocked with the same clock as the regular sofa and 
j we' 11 want topt to be able to do a good job on the main interfaces. 
(Can you get this data together please? 

bpw and I released what should be a complete set of topt numbers for iobytem 
yesterday. Please let me know if there are any problems. 


Brian L. 
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From: ken (Ken Hsieh) 

Sent: Tuesday, February 14, 1995 11:54 AM 

To: 'Lisa Robinson' 

Cc: 'sysadm'; 'mws (Mark Semmelmeyer)' 

Subject: Re: sysproto 

> 

> I'm not sure. Maybe it is just not visible from the machine you 

> are using. I know we have had problems with this partition not being 

> visible, in fact at one point I had thought that it wasn't being 

> exported. 

> 

> Lisa R. 

> 
> 
> 

> Begin Included Message 

> 

> >From mws Mon Feb 13 19:34:07 1995 

> Return-Path: <mws> 

> Received: from cIytemnestra.microunity.com by gaea.microunity.com (4.1/musel.3) 

> id AA23086; Mon, 1 3 Feb 95 1 9:34:04 PST 

> Received: from localhost by clytemnestra.microunity.com (8.6.4/muse-sw.3) 

> idTAA20166; Mon, 13 Feb 1995 19:33:51 -0800 

> From: mws (Mark Semmelmeyer) 

> Message-Id: <199502140333.TAA20166@clytemnestra.microunity.com> 

> Subject: Re: sysproto 

> To: Hsar@MicroUnity.com (Lisa Robinson) 

> Date: Mon, 13 Feb 95 19:33:48 PST 

> In-Reply-To: <199502140313.TAA13136@nosferatu.microunity.com>; from "Lisa Robinson" at Feb 13, 95 7:13 pm 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content-Length: 410 

> X-Lines: 12 

> Status: RO 
> 

> > 

> > /n/rhodan/s3/euterpe/verilog/bsrc/res/l 3295.2997/results/sysproto2_l .dpo 

> > 

> > Lisa R. 

> > 
> 

> Hmmm. The res directory is a soft link: 

> mws clytemnestra(7):/n/rhodan/s3/euterpe> Is -1 !$ 

> Is -1 verilog/bsrc/res 

> lrwxrwxrwx 1 lisar 7 Jan 26 16:42 verilog/bsrc/res -> /s2/res 
I have changed the pointer to 

lrwxrwxrwx 1 lisar 16 Feb 14 09:50 res -> /n/rhodan/s2/res 
So, you will be able to access it from any place. 

Ken 
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> not visible unless I am logged onto rhodan. I wonder if this is one 

> of those file system weirdnesses or expected. 

> 
> 

> End Included Message 

> 
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From: tbr 

Sent: Tuesday, February 14, 1995 12:24 PM 

To: 'brianl (Brian Lee)' 

Cc: 'age (Alan Cony)'; 'bpw (B. P. Wong)'; Vanthof (Dave Van't Hof)' 

Subject: Re: Timing model 
Follow Up Flag: Follow up 

Flag Status: Red 


Brian Lee wrote (on Tue Feb 14): 

Tim B. Robinson writes: 

I 

| We will need an accurate timing model for topt for iobytem, the 
(version of iobyte in mnemosyne. Unlike the euterpe version, this one 
[is designed to be clocked with the same clock as the regular sofa and 
Jwe'll want topt to be able to do a good job on the main interfaces, 
j Can you get this data together please? 

bpw and I released what should be a complete set of topt numbers for iobytem 
yesterday. Please let me know if there are any problems. 

Thanks. 

Tim 
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From: 
Sent: 
To: 


Cc: 

Subject: 


vanthof (vant) 

Tuesday, February 14, 1995 4:51 PM 

'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; Vo (Tom Vo)'; 'tbr (Tim B. Robinson)'; 'lisar 
(Lisa Robinson)' 

'vanthof (Dave Van't Hof)'; 'torn (Thomas Laidig)' 
a euterpe vss/vdd short found 


Finally, a short was found. Tom and I tracked down the elusive short. 
Turns 

out the mobiecliumjaoxistors cell is not symetrical. This is okay when two (one normal, 
one flipped) are placed next to each other, however, when those two overlap, a vdd/vss 
short is formed. Just such an overlap occured at (7668 0, 190820) . A column of 
mobieclium_noxistors was flipped and overlapped with a non-flipped column. I've centered 
the opening, checked it in, and started a releasebom for that cell. 

I'm going to start up two shorts checks; metals only and all layers. I want the metals 
shorts check to complete before I disappear for a while. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering , 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for himi 


Thanks , 
Dave 
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From: noel (Noel Verbiest) 

Sent: Tuesday, February 14, 1995 6:52 PM 

To: 'graham'; 'wayne' 

Cc: 'dane'; "tbr" 

Subject: Re: Hold-up time 

> From wayne Mon Feb 13 10:51:02 1995 

> Date: Mon, 13 Feb 1995 10:51:00 -0800 

> From: wayne (Wayne Freitas) 

> To: graham 

> Subject: Re: Hold-up time 

> Cc: dane, tbr, noel 

> Content-Length: 2447 

> 

> > 

> > I made a mistake in the arithmetic when we discussed 

> > hold-up time of the PSU in my office. 

> > 

> > 470uF with 1 amp drawn and a droop of 30V results in 

> > about 15 milliseconds. If the spec is 32mS, the capacitance 

> > is not adequate. 

> > 

> > I suspect that Noel calculated this earlier using a more 

> > optimistic droop, >30 volts, 

> > 

> > Graham. 

>> 
> 

> Graham, this is what I have. 

> 

> The spec says that we must run on a AC Voltage of 120V AC +/- 

> 20% at a frquency of 57 to 63Hz. 

> 
> 

> Using the following equation you get a DC voltage out 

> of the AC-DC board of: 

> 

> Voavg - [(sqrt2 * Vin) *2] - Vf 

> Vo = Output Voltage 

> Vin = Input Voltage (AC) 

> Vf = Internal Voltage drop (~ 5 volts) 

> 

> — Average — 

> Vin= 120VAC 

> Voavg = (sqrt2 * 120) *2 -5 = 334.4Volts DC. 

> 

> —Worst Case — 

> Vin = 96VAC 

> Voavg = (sqrt2 * 96) *2 -5 = 266.5Volts DC. 

> 

> The below equation comes from a power supply manufacturer for 

> calculating minimum capacitance value for hold-up time. 

> 

> Co(eff) - 2 * Pin * Th 
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> [(Vo - Vp-p) A 2 - (Vdo) A 2] 

> 

> Co(eff) = Total effective capacitance value 

> Pin = Total system input power requirements 

> Vo = DC output rectified unregulated voltage 

> Vp-p = Rjpple voltage 

> Vdo = Dropout voltage of DC module 

> Th = Output hold time 
> 

> If I assume Euterpe uses 28 A @ 3.3 V, and Calliope uses 1 7 A 

> at 3.3V you get 45 A @ 3.3V. I don't have all the numbers so 

> I won't add anything on for the SDRAM's or FlashROM, etc. 

> In addition we have a 3 A rating for the +5 and a total of 3A 

> rated for the +12 (reg & unreg). The RO spec's 240V minimum 

> (Vdo). I've seen the spec on two different vendors for ripple 

> voltage around 25V, but I'll be aggresive and use 40V. So if 

> we use the above equation I get the following: 
> 

> Example 1 Pin = 45A @ 3.3V, 1A @ 5.0V and 1 A @12V =165.5W 

> using a 73% effiency rating for the DC 

> DC Module requires 227W. 

> 

> Example 2 Pin = 45A & 3.3V, 3A @ 5.0V and 3A @12V =200W 

> using the same effiency rating would 

> then require 274 W. This is close to worst 

> case condition. 

> 

> 2 * 227 * .032 14.528 

> = = 500uF 

> (334.4 - 40) A 2 - (240) A 2 86,671 - 57,600 


> 2 * 274 *. 032 17.536 

> = = 24,280uF 

> (266.5 - 25) A 2 - (240) A 2 58,322 - 57,600 

> 
> 
> 

If I remember correctly, the 470 microfd was a compromise that would give us a 16 mS hold-up 

time at +/- 10% line voltage variation and that would fit in a housing of acceptable size. 

I don't have my notes here but seem to remember that we went that direction when it became 

obvious that the Hestia boxes would become "technology demonstrators" rather then low-cost 

high volume consumer products, (middle of last year ?). 

Noel @ home. 238 6003 
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Subject: 


Sent: 

To: 

Cc: 


From: 


paulb (Paul Berry) 

Tuesday, February 14, 1995 7:13 PM 
'tbr' 

'd buffer'; 'lisar'; 'pandora' 
Pandora Notes 


I released an update to the Pandora notes files. 
They are visible in /u/chip/pandora/doc/notes . 

You can also get there by executing "central" (in a Unix shell) or in Mosaic, from the 
MicroUnity home page, select "chip home page". 

>From either of those starting points, select 
MediaComputer : Pandora : MeetingNotes 

That gives you the table of contents with hypertext links. 
Click any entry to go to it . 

A paper copy is in a white binder on my desk (all 164 pages!) (sorry for all that 
printing, Lisa) . 
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From: vanthof (vant) 

Sent: Tuesday, February 14, 1995 7:32 PM 

To: 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)'; 'lisar (Lisa Robinson)'; Tom Vo'; Tim B. 
Robinson' 

Cc: Vanthof (Dave Van't Hof)' 

Subject: drc/lvs(shorts) status 


euterpe: 

floating poly: 

running on tomato. Should be done thursday morning, 
drc: 

lower; should be clean, edits done today for mnemo cells may have 
affected these layers, but cache drc will catch them. 

upper; should be clean. Only errors left are notches from router 
and via twinning. 

Ivs(shorts): 

running on medsua, metals only. Hopefully clean. Should be done 
tomorrrow sometime, maybe early thursday. If clean, lvs runs can start. 

mnemo: 

drc: 

lower; pretty dirty. The mb block was not clean and after many edits 
today is still not clean. I've fixed many errors only to 
create different errors. Professional help will be needed. 

upper; only thing left that I know of is the pll... When it's ready 
another fiillchip can be started. This is supposed to be 
ready tomorrow morning. 

lvs(shorts): 
none run yet. 

mb block; 

drc: 

lower; most of mnemo's errors were here. I've fixed many only to 
introduce more. The fix is straight forward, but device size 
changes are in order and I want BP and stick to look at it 
before that happens. The drc results will be done by morning. 

cache block: 

drc: 

lower; should be done by morning. Only run to verify my edits to 
cache cell used in mb block did not mess up anything in cache. 

I've locked down and released all cells modified today. Another GETBOM 
can be done at anytime. The GETBOM is not holding me up, but may be useful 
for future baseplate makes and routes. 
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More later, 
Dave 

Dave Van't Hof vanthof@microunity,com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> 
Don't blame me, I didn't vote for him! 
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From: vicki [vicki@charybdis] 

Sent: Tuesday, February 14, 1995 7:40 PM 

To: 'Geert Rosseel' 

Subject: Call Lieve at home 


euterpe : 

floating poly: 

running on tomato. Should be done thursday morning. 

drc : 

lower; should be clean. edits done today for mnemo cells may have 
affected these layers, but cache drc will catch them. 

upper; should be clean. Only errors left are notches from router 

and via twinning. 

lvs ( shorts) : 

running on medsua, metals only. Hopefully clean. Should be done 
tomorrrow sometime, maybe early thursday. If clean, lvs runs can start. 

mnemo : 

drc : 

lower; pretty dirty. The mb block was not clean and after many 

edits 

today is still not clean. I've fixed many errors only to 
create different errors. Professional help will be needed. 

upper; only thing left that I know of is the pll... When it's 

ready 

another fullchip can be started. This is supposed to be 
ready tomorrow morning. 

lvs (shorts) : 
none run yet. 

mb block: 

drc : 

lower; most of mnemo ' s errors were here. I've fixed many only to 

introduce more. The fix is straight forward, but device size 
changes are in order and I want BP and stick to look at it 
before that happens. The drc results will be done by morning. 

cache block: 
drc: 

lower; should be done by morning. Only run to verify my edits to 

cache cell used in mb block did not mess up anything in cache. 

I've locked down and released all cells modified today. Another GETBOM can be done at 
anytime. The GETBOM is not holding me up, but may be useful for future baseplate makes 
and routes. 

More later, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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From: tbr (Tim B. Robinson) 

Sent: Tuesday, February 14, 1995 8:09 PM 

To: 'craig' 

Cc: 'dickson' 

Subject: Euterpe Cerberus issues 


Rich has a couple of issues on the Euterpe Cerberus. Can you find some time tomorrow 
wwhen we can meet to discuss them? 

Tim 
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From: tbr 

Sent: Tuesday, February 14, 1995 8:25 PM 

To: Vanthof (vant)' 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; Thomas Laidig'; 

'Dave Van't Hof ; Tom Vo' 

Subject: a euterpe vss/vdd short found 

Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Tue Feb 14): 


Finally, a short was found. Tom and I tracked down the elusive short. Turns 

out the mobiecliumnoxistors cell is not symetrical. This is okay when 

two (one normal, one flipped) are placed next to each other, however, when 

those two overlap, a vdd/vss short is formed. Just such an overlap occured 

at (76680, 190820). A column of mobieclium_noxistors was flipped and overlapped 

with a non-flipped column. I've centered the opening, checked it in, and 

started a releasebom for that cell. 

I'm going to start up two shorts checks; metals only and all layers. I want 
the metals shorts check to complete before I disappear for a while. 

I'll pick up another BOM inot the snapshot to get this. 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, February 14, 1995 8:25 PM 

'vanthof (vant)' 

'geert (Geerl Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'torn (Thomas 
Laidig)'; Vanthof (Dave Van't Hof)'; Vo (Tom Vo)' 
a euterpe vss/vdd short found 


vant wrote (on Tue Feb 14) : 


Finally, a short was found. Ton and I tracked down the elusive short. 
Turns 

out the mobieclium_noxistors cell is not symetrical . This is okay when 

two (one normal , one flipped) are placed next to each other, however, when 

those two overlap, a vdd/vss short is formed. Just such an overlap occured 

at (76680, 190820). A column of mobieclium_noxistors was flipped and overlapped 

with a non- flipped column. I've centered the opening, checked it in, and 

started a releasebom for that cell. 

I'm going to start up two shorts checks; metals only and all layers. I want 
the metals shorts check to complete before I disappear for a while. 

I ' 11 pick up another BOM inot the snapshot to get this . 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Wednesday, February 15, 1995 12:42 AM 

Vant' 

'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson}'; 'vo (Tom Vo)'; 'geert (Geert Rosseel)'; 'vanthof 
(Dave Van't Hof)' 

Re: short no longer in metals for euterpe 


vant writes : 

The short in the metal layers is gone from euterpe. I'm now starting up a 
full layer shorts check which will be done in about 3 days. 

Thanks , 
Dave 

Great work, Dave and Tom! 

-thanks, 
hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Wednesday, February 15, 1995 3:08 AM 

Vant' 

'geert (Geert Rosseel)'; 'wampler (Kurt Wampler)'; 'tbr (Tim B. Robinson)'; Vanthof (Dave 
Van't Hot)'; "torn (Thomas Laidig)' 
Re: euterpe plot on hp650 


vant writes: 

The euterpe plot on the hp650 came out looking really good. I've plotted 
metals 3, 4, and 5. To generate the data took less time than for the 
versatec as it only generated a 8.9MB HPGL/2 file instead of a larger 
raster image file. To plot the data only took 10-15 minutes, basically the 
time it took to move the head back and forth for the entire plot. Very few 
pauses . 

I like this plotter. NO nasty chemicals, easy maintenance, cuts the paper 
for you, small, no noise. I can go on. . . 

I have one plotted already, I think I'll go make another copy... 


I second that I 

Frank is working on the net interface but I think on the basis of what we have seen I'd 
like to put in a PR for the HP-GL hyperplot filter ($2500) and perhaps a parallel cable 
($75?) . 


Thanks , 
Dave 


- thanks , 
hopper 
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From: vanthof (vant) 

Sent: Wednesday, February 15, 1995 8:23 AM 

To: 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'vo (Tom Vo)'; 'hopper (Mark Hofmann)'; 'geert 

(Geert Rosseel)' 
Cc: 'vanthof (Dave Van't Hot)' 

Subject: short no longer in metals for euterpe 


The short in the metal layers is gone from euterpe. I'm now starting up a full layer 
shorts check which will be done in about 3 days. 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X2 76 # include <std_disclaim. h> Don't blame 
me, I didn't vote for him! 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, February 15, 1995 9:31 AM 

To: 'billz'; 'dickson*; 'jeffm 1 ; 'mws'; 'tbr'; 'woody' 

Subject: Test status 


BOM 229 running on Zycad 
BOM 22 9 running on IKOS 

Note dcacheharder2 and 3 ran ok 

New business 


brmisstest_0 229 - Failed - problem understood 

sysproto2 229 - Dump available - problem understood 

exlltest2 229 - Trace available rhodan: 

/s3/euterpe/verilog/bsrc/res/142954 . 9258 

dcache_func_l 229 - } 

dcache_sz_4k_l 229 - } - Xall look to be the same 

dcache_sz_8k_l 229 - } trace on rhodan: 

/s3/euterpe/verilog/bsrc/res/l4295 . 15362 
dcache_sz_16k_l 229 - } 

gtlbtran_l 22 9 - X tracing now Note may also be detecting a 

hazard accessing cache or tag 

barrel_l 229 - running now 

hermes_0 229 - X trace on nosferatu 14295.? dumping now 

nosf eratu : / s2 /euterpe/verilog/bsrc 
iorupttest_0 22 9 - X trace on 

nosferatu: /s2/euterpe/verilog/bsrc2/res/152 95 . 11881/results/iorupttest . dpo 
, dumping now 

knobharder 229 - X Looks like write to cerberus register of 

0000000000005555 results in 0000000055550000 

as reported by snoopy. The test then goes to X 


exlocktest_0 
exrleasy 


229 

229 - went to bad (expected) 


} 
} 

} 22 9 - all went to bad (expected) 


exlStest 

exresgcmpritestl_0 
exresgexpitestl_0 } 
exresgmshritestl_0 
exresgrotritestl__0 
exresgshlitestl_0 } 
exresgshritestl_0 } 
exresgucmpritestl_0 } 
exresguexpitestl_0 } 
exresgushritestl_0 } 

Old Business - Need to reun and if necessary redurap these 

icache_func_l 223 New trace in 6295.1883 7 on rhodan /s3 

watchtest 223 - X - Doesn't seem to be taking a machine 

check, trying to get a dump 

xlu_f ield_5_l 223 - X - trace 

/n/rhodan/s3/euterpe/verilog/bsrc/res/4295 . 29774 trying to get a dump 


icache sz 4k 1 


223 } traces in 5295.7249 Jeff these are for you: 
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icache_sz_8k_l 
icache_sz_16k_l 

uncruptharder_0 

bgateJJ 

cerbarbeasy_0 

gtlb_miss_l 

Need sync ops : 


223 } 
223 } 

22 0 - Dump on nosferatu /s2 


Lisa R to run again as verilog run is well behaved 
223 - X rhodan /s3 8295.13771 


saaseasy 218 

scaseasy 218 

saastest_0 

scastest_0 

nb_slow 

7295.19105 

nb_l 

nb_hermes_l 

nb_combo_l 

dcache_stress_l 

dcache_per f _ldst 5 t_l 

icache_stress_l 

icache_perf_5t_l 

align_at _1 

fva_conf lict_l 
herraes_conf lict_l 
dcache_conf lict__l 
atomic_conf lict_l 

oc - synch_U 
synch_l 

Have not yet been run: 


Dump on nosferatu /s2 - Problem understood 

223 - Running a longgggg time trace on rhodan /s3 


doubleextest_0 
doublemctest_0 
cerbstarttesto 
ruptpintest_0 

dcache_except_l 


Need to build a "custom" simulator iorupttest_0 
- Need to build a "custom" simulator 


dcache_perf_ldlt_l 
dcache_perf_stlt_l 
dcache_j?erf_ldstlt _1 

addr_map_dram 

interrupt_l 
cache_l 
exception 1 
bgate_l 
barrel_l 

interrupt_U 

except ion_U 

bgate_U 

mem_U 

tlb_U 

synch_U 

barrelJJ 

cache_U 

gtlb_miss_U 


Cannot yet be run: 
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instr_U 

instr_l 

tlb_l 

insn_l 

nulltest 

unix 

XLU tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand_l_l 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_field_2_l 

xlu_field_3_l 

xlu_f ield_4_l 

xlu_copyswap_l_l 

xlu_copyswap_2_l 

x 1 u_copy swap_3 l 

x 1 u_copy swap_4 _1 

xlu_shuf f lemux_l_l 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlongtest_0 

expriotest_0 

canceltest_0 

he rm t o t e s t_0 

cerbtotest_0 

hermerrtest_0 

eventregtest_0 

exintbashtest_0 

cerb__registers_0 

cerberror_0 

testerinit_0 

memmap_0 

nbbashtest_0 

cerbraw_0 

cerbarbtests 

hcplltests 
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Cc: 

Subject: 


From: 
Sent: 
To: 


vanthof (vant) 

Wednesday, February 15, 1995 9:38 AM 

'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'wampler (Kurt Wampler)'; 'tbr (Tim B. 
Robinson)' 

Vanthof (Dave Van't Hof)'; 'torn (Thomas Laidig)' 
euterpe plot on hp650 


The euterpe plot on the hp650 came out looking really good. I've plotted metals 3, 4, and 
5 . To generate the data took less time than for the versatec as it only generated a 8 . 9MB 
HPGL/2 file instead of a larger raster image file. To plot the data only took 10-15 
minutes, basically the time it took to move the head back and forth for the entire plot. 
Very few pauses . 

I like this plotter. NO nasty chemicals, easy maintenance, cuts the paper for you, small, 
no noise. I can go on. . . 

I have one plotted already, I think I'll go make another copy... 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ^include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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Subject: 


Sent: 

To: 

Cc: 


From: 


bobm (Bob Morgan) 

Wednesday, February 15, 1995 10:09 AM 

'Paul Berry' 

'craig' 

Re: Pandora Notes 


The mosaic interface doesn't work yet. I forgot to put a link to the central script in 
there instead of direct links. I'll do that now, or you can just type in central. 
Bob 

In article <199502150113 . RAA07853@mercury .microunity . com>, you write: 

> I released an update to the Pandora notes files. 
> 

> They are visible in /u/chip/pandora/doc/notes . 
> 

> You can also get there by executing "central" (in a Unix shell) or in 

> Mosaic, from the MicroUnity home page, select "chip home page". 
> 

> From either of those starting points, select 

> MediaComputer : Pandora : MeetingNotes 
> 

> That gives you the table of contents with hypertext links. 

> Click any entry to go to it. 
> 

> A paper copy is in a white binder on my desk (all 164 pages!) (sorry 

> for all that printing, Lisa) . 
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Sent: 
To: 

Subject: 


From: 


tbr 

Wednesday, February 15, 1995 11:44 AM 
'hopper (Mark Hofmann)' 
Re: euterpe plot on hp650 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofmann wrote (on Wed Feb 1 5): 
I second that! 

Frank is working on the net interface but I think on the basis of what we 
have seen I'd like to put in a PR for the HP-GL hyperplot filter ($2500) 
and perhaps a parallel cable ($75?). 

We need to meet briefly with dbulfer, tbe, albers, and fgp, to make 
sure we can set this up so as not impact what the mechanical/pcb folks 
need to do 
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From: 
Sent: 
To: 

Subject: 


bobm (Bob Morgan) 

Wednesday, February 15, 1995 12:13 PM 
'euterpe' 

Release 1.7 of microarchitecture 


Hi, 

I've released version 1.7 of the microarchitecture document. Highlights include: 

- clarification of xlu shift information 

- corrections to cache/buffer configuration table , 
with explanations of the tag area 

- changes to cerberus octlet 7 

As always, you can print off a copy by typing "make book" 

in the euterpe/doc directory, or let me know and I'll print off a bound copy for you. 

I'll be out for the rest of the day, but I'll get to all requests first thing in the 

morning . 

Thanks, 

Bob 


Exhibit Cll 


Page 314 of 559 


From: 


tbr 


To: 


Subject: 


Sent: 


Wednesday, February 15, 1995 12:48 PM 
'torn' 

snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 


It failed again, but different this time: 


/n/auspex/s23/euterpe-proteus-cp/tools/bin/sofa-stats -f -e -v /n/auspex/s23/euterpe-proteus-cp/compass/v!si. boo-all -l 
scsxl /n/auspex/s23/euterpe-proteus-cp/custom/edif/scsxl .edif \ 

> scsxl. tmp.eclstats 
***** READ Unexpected end-of-file 
(SCRT6 DEFAULT-ERROR-HANDLER ...) 
(listutil_12636 [inside TOP-LEVEL] ...) 
(ERROR ...) 

(SCRT7 NEXT-CHAR ...) 
(SCRT7 TOKEN ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST .„) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7JDATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 
(SCRT7_DATUM-LIST ...) 

gmake[2]: *** [/n/auspex/s23/euterpe-proteus-cp/custom/stats-tmp/scsxl.eclstats] Error 1 
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From: tbr 

Sent: Wednesday, February 15, 1995 12:49 PM 

To: 'bobm (Bob Morgan)' 

Subject: Release 1 .7 of microarchitecture 

Follow Up Flag: Follow up 

Flag Status: Red 

Bob Morgan wrote (on Wed Feb 15): 
Hi, 

I've released version 1 .7 of the microarchitecture 
document. Highlights include: 

- clarification of xlu shift information 

- corrections to cache/buffer configuration table, 
with explanations of the tag area 

- changes to cerberus octlet 7 

As always, you can print off a copy by typing "make book" 
in the euterpe/doc directory, or let me know and I'll print 
off a bound copy for you. I'll be out for the rest of the 
day, but I'll get to all requests first thing in the morning. 
Thanks, 
Bob 

I'll go for the ready made version as usual, please. 
Tim 
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From: geert (Geert Rosseel) 

Sent: Wednesday, February 15, 1995 12:59 PM 

To: 'tbr'; 'torn' 

Cc: 'bill'; 'hopper'; 'tau' 

Subject: Re: snapshot update failure 

> Thanks torn, I restarted it. I think this highlights a problem with us 

> not snapshoting the tools at the same time as everything else . . . 

Yes, snapshotting the tools would be nice ... In building 
the top-levelk Euterpe, I've been very isolated from the rest 
of the world which has been really a great help. The only times 
I've run into trouble is when tools unexpectedly change. 

Geert 
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From: torn (Tom Laidig (tau)) 

Sent: Wednesday, February 15, 1995 1:20 PM 

To: Tim B. Robinson' 

Cc: 'tau' 

Subject: Re: snapshot 

Tim B. Robinson writes: 


jit failed again, but different this time: 


|/n/auspex/s23/euterpe-proteus-cp/tools/bin/sofa-stats -f -e -v /n/auspex/s23/euterpe-proteus-cp/compass/vl si. boo-all -1 
scsxl /iVauspex/s23/euterpe-proteus-cp/custom/edif/scsxl .edif \ 
| > scsxl. tmp.eclstats 

|***** READ Unexpected end-of-file 
[etc] 

Oh. This is the partial proteus/custom/edif/scsxl .edif file that 
ged2edif generated last time. Perhaps the Makefile rule for running 
ged2edif should do the old 

$(GED2EDIF) -o tmp ... 
mv tmp $@ 

kind of thing. 

Anyway, removing it and retrying should get you past this problem spot. 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, February 15, 1995 2:22 PM 

To: 'Frank Paturzo' 

Cc: 'vanthof (Dave Van't Hof)'; 'sysadmin' 

Subject: Re: slip line problems? 

Frank Paturzo writes: 

This sounds very much like kleanthes' problem with hades. 

Only eric can answer if we've had any routing changes. 
Frank and Eric, 

Dave is doing critical tapeout work. In addition he will be working 
from home a good deal in the coming weeks. Is there something you can 
try to fix Frank? If not, perhaps I should page Eric. 

-thanks, 
hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisar (Lisa Robinson) 

Wednesday, February 15, 1995 8:28 PM 

'woody'; 'mws' 

'billz'; 'tbr'; 'jeffm'; 'dickson' 

test6_0 


It looks like that now a correct value for nticks is being passed into the bramz models, 
we are seeing some genuine dbuffer hazard cases. 

test6_0, a very simple test, seems to be hitting such a case. 

The dump file in aphrodite : /s3/euterpe/verilog/bsrc/test6_0 .dump does fab (since Jeffs 
model is a zycad model only the zycad run goes to x) . 

On the zycad, the model detects a problem at simtick 13 3 5101 now we come out of reset at 
about 600240 on the zycad and 18480 in verilog so you should see the failure at about 
simtick 753341 in the verilog dump. 


Lisa R. 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Thursday, February 16, 1995 12:34 AM 

'geert'; 'vo' 

Re: Problem with rload 


Geert writes: 


> I looked at the rload results and it look s like all the XLU wires are 
>routed in fat-wires. Before I did the rload, I did the hwc route. I 
>need to do that because the hwc route cleans up all the routing before 
>it starts. I think something does not get properly reset after the hwc 
>route is done. 

Vo replies : 


>The hwc route step should do nets from these 2 files in order : 
> 

>analog_euterpe . hwc then 

>clockbias . hwc . 

> 

>clockbias . hwc has just 0 . 5u for the widths , so after the hwc route 
>step , everything should be back to thin wires . 

It's probably safest at this point to blow away your ".dff" file and 
start over again from the PCOMP/GPLACE step, after making sure that 
you're doing things in the preferred order. I would preload the XLU 
stuff first, and then run the hwcroute passes. 

If hwcroute dies and leaves the default wire width at some fat value, 
there is a script that you can use to reset the wire width: 

/u/chip/tools/bin/set_fatwires -design {your_design} -width 0.5 


- Kurt 
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From: geert (Geert Rosseel) 

Sent: Thursday, February 16, 1995 7:59 AM 

To: 'billz'; 'dickson'; 'hopper'; 'lisar'; 'mws'; "tbr 1 ; 'wampler'; 'woody' 

Cc: Vo' 

Subject: New datapath route 


Hi, 

I picked up Rich Dickson's new datapth and the number of unroutes using 
linesearch only went from 5100 to 3500. We are now at 98.7%, up from 
98.07%. I have not looked at the results yet. 

I konw there are two more areas of congestion : one is wires 
getting out of cerberus. This may need cerberus placement changes. The 
other one is gt/sr/at/nb. 

If anyone has some time, can you please look at the result. We should 
meet later today to decide on what to do next. 

The result is in /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards/geert_euterpe-iter.dff 
(Tol ook at it, you'll have to link tothe dff and make a local copy of the vrf file) 
Geert 
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From: lisar (Lisa Robinson) 

Sent: Thursday, February 16, 1995 8:22 AM 

To: 'mws'; 'woody' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'tbr' 

Subject: BOM230 

Good Morning. 

Well there are some failures with BOM 230. Dcacheannoying was the first. 
I ran the _0 version onchip in verilog and it fabbed so I have 
just started it up again off chip. 

The likedriverlog traces are in /s3/euterpe/verilog/bsrc/res/15295.27225/results 
on rhodan. 


Here is the list of failures: 

dcacheannoyingO (looks like X's) Failed 
icacheharder O (looks like X's) Failed 
icachemiss_0 (looks like X's) Failed 
icacheannoying_0 (looks like X's) Failed 
sysprotol_l Failed 

Here is what ran ok: 

test!0_0 Ran ok 
load 0 Ran ok 
store_unique_0 Ran ok 
cystoreload_0 Ran ok 
memtestO Ran ok 
ibuf storeeasy 0 Ran ok 
itag_storeeasy_0 Ran ok 
dtag_storeeasy_0 Ran ok 
ltlb_0 Ran ok 
gtlb_0 Ran ok 
gtlbaccess4_0 Ran ok 
gtlbmisseasy_0 Ran ok 
dcacheeasy_0 Ran ok 
dcacheharderj) Ran ok 
dcachenoallocO Ran ok 
nbuseeasy jO Ran ok 
nbfulltest_0 Ran ok 
nbhiprio_0 Ran ok 
dram_load_0 Ran ok 
dram_store_unique_0 Ran ok 
dramharderO Ran ok 
bdownharderO Ran ok 
sysproto2 1 Ran ok 
cerbeasy_0 Ran ok 

Lisa R. 
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From: geert (Geert Rosseel) 

Sent: Thursday, February 16, 1995 8:31 AM 

To: 'wampler' 

Cc: 'dickson'; "tbr"; Vo' 

Subject: Euterpe route 

Hi Kurt, 

The latest euterpe stil Ihas a lot of : 
** GAROUT warning: 41 

Apparent pin/routing obstruction overlap at grid (8353,750). 

What do these mean ? Is that a result of routing congestion ? or 
can we do something aabout this ? 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Thursday, February 16, 1995 10:13 AM 

'geert' 

'dickson'; 'tor'; 'vo' 
Re: Euterpe route 


Geert writes: 


> Hi Kurt, 
> 

> The latest euterpe stil lhas a lot of : 
> 

> ** GAROUT warning: 41 
> 

> Apparent pin/routing obstruction overlap at grid (83 53,750). 
> 

> What do these mean ? Is that a result of routing congestion ? or can 
>we do something aabout this ? 

> 

> Geert 

There's a pretty low signal to noise ratio with this particular warning 
message message. GAROUT emits these messages for all clock pins that are 
hooked to the non- global -sofa clock in the netlist, and also for many of 
the custom blocks that have M3 or M4 targets floating over a sheet of M2 . 
There might be some real target modelling problems lurking in amidst all 
of these, but all the ones I've randomly audited are "don't-cares" like 
the above two cases. I can't right now think of an easy automated way 
to distinguish between the care & don't-care situations... Ideas, 
anyone? 


- Kurt 
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From: doi (Derek Iverson) 

Sent: Thursday, February 16, 1995 10:32 AM 

To: 'lisar (Lisa Robinson)' 

Cc: 'jeffm'; 'tbr' 

Subject: reg depend 

Lisa Robinson writes: 

> 

> I don't seem to be able to create regdepend tests that contain "all" of the 

> instructions, I get regdepend_r23069.S:3922: Error: Invalid operands (u < 64 || v < 64) to gcopyswapiswap 

> 

> even when I put gcopyswapiswap in the exclyde file. 

Hmmm. If gcopyswapiswap is in the exclude file it should not appear 
in generated assembly code. 

There was a bug in the assembler that was telling us we were using 
invalid operands erroneously. I am pretty sure lisa checked in a fix 
for this though. 

I looked in /n/nosferatu/s2/euterpe/verify /random at the regdepend file 
and noticed a gcopyswapl li instruction at line 3922 instead of a 
gcopyswapiswap. Hmmm. I will have to look at this when I get in. 

doi 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Thursday, February 16, 1995 1:39 PM 

'geert' 

early short nets 


Hi, 


Browsing around in the latest Euterpe gards area, I notice that the early short nets file 
is empty. In order for the selection of short nets to work properly, the G PLACE placement 
step needs to be complete. Is it possible that the dependency order in the Makefile is 
such that the selection operation was run * before* the components were placed? That could 
account for the empty file. 

When I run the net_select program on your current placement, it identifies 
119 

early short nets. 


- Kurt 
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Subject: 


From: 
Sent: 
To: 
Cc: 


doi (Derek Iverson) 

Thursday, February 16, 1995 5:24 PM 

'gmo'; 'sandeep'; 'guarino'; 'wayne'; 'gregg'; 'jeffm'; 'dbulfer' 

'hestia' 

Software Bringup Meeting Minutes - February 15, 1995 


Software Bringup Meeting 


February 15, 1995 


Next Meeting: 


February 22 at 10:00 am. 


Attendees: guarino, gmo, gregg, sandeep, wayne, doi 


New Action Items 


None. (Just additions to existing action items) 


Review of Action Items 


Item: Running Real-time Benchmark on Euterpe/Calliope HW Simulator 

(combined with previous "Run real-time test on the HW simulator) 
Who: gregg, lisar 
Status: In Progress. 

02/08 There are problems getting the benchmark to run on the 
software simulator. Work continues to find out where 
the problems are. The compilers, simulator, kernel, and 
benchmark areas are "frozen 1 (in terms of checking in 
new changes) until the problem has been identified. 

02/15 It is estimated that by the middle of March we should have 
cycles available on the IKOS and a IKOS compatible calliope 
that can be run with the real-time benchmark. 
Lisar will be the verification resource to help with running 
this application. 

The benchmark is working and now the effort is focused on 
getting it to fit in the real-time and memory budgets. 


Item: Specify and Design ISA/Cerberus Card 
Who: gmo, lisar, dbulfer 
Status : Pending 

gmo, lisar, and dbulfer own the problem of specifying 
the design and assigning resources. 


Item: Determine what additional terp features are required 

(formally "Status of Euterpe/Mnemo simulation 1 ) 
Who: gmo, jeffm 
Status : Pending , 

02/08 Jeffm figured that in 2 - 3 weeks time there would be a need 
for terp/mnemo capability to support the verification effort. 
An issue was raised that this may not be enought time for the 


Exhibit Cll 


Page 328 of 559 


required additions to terp to be made. 
02/15 Gmo is to create a list of requested features for terp and 
then he and jeffm (and others?) are to review the list and 
determine what will be implemented by terp. 


Item: Test interleaved access 
Who : guarino 
Status : Pending . 

02/08 Loretta started to look at this but requires terp support. 
Terp changes are on hold until the real-time benchmark is 
is running again. 


Item: Build microkernel tests for IKOS 
Who: doi, sandeep, iimura 

Status: In progress. Expected completion 2/15 

02/08 Create images for boot test, snapshot images for microkernel 
tests . 

02/15 doi is still working on modifying the makefiles to build 
the _1 and _2 versions of this . 

iimura is creating a tool that modifies the ELF headers to 
have the proper real addresses (not just virtual) and gmo has 
modified mkimg to be able to understand the new headers. 

Item: DVT boot 
Who : doi 

Status: In progress. 

02/08 First step is to get nano-boot running on the HW simulator. 

02/15 Sandeep has completed the boot code and now we need to 
build a dvt that can be loaded by the DVT boot (i.e. it 
is loaded into the top 8K of D and I buffer) . 
Jeffm commented that for most DVTs, they must be loaded at 
the beginning of D and I buffer and the beginning of ram. 
We will have to come up with an alternative for loading 
DVTs . 

Sandeep noted that dvts will not be started in event mode 
which is in contrast to jeffm' s mail about the initial state 
for dvts (but we knew this already) . 


Item: Unsnap code 

Who : sandeep , guarino 

Status : Pending . 

02/15 The issue of restarting the hardware from an IKOS dump 

was discussed and the need for an architectural snap/unsnap 
facility was questioned. 

Since the meeting it has been re-discovered (jeffm wasn't there 
to remind us of an earlier decision) that we are planning on 
loading architectural state into an IKOS simulation and not 
from a total IKOS logic dump. 

We also determined that when it came time to run some 
of the larger tests (real-time benchmark) we would need 
the capability to start an IKOS simulation from an 
architectural dump anyhow. 


Suspended Items 


Item: Refine remote debugging environment 

Who : sandeep 

Status: Suspended 
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02/08 We have to decide how control (and state) is to be returned 

to the debug stub after a test runs. 
02/15 Sandeep is not going to have time to start on this for a while. 


Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/30] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware . 


Completed Items 


Item: IKOS support for "fake calliope" 
Who: jeffm 
Status: Deleted 

02/08 In order to run our realtime benchmark test, we need some way 
to get data in and out of the HW simulator at the speed 
of a Calliope access. We would also like some way to cause 
fake calliope events to be posted at regular intervals. 

A number of possibilities were discussed during the meeting: 

o add a fake calliope to the verilog/zycad hermes model, 
o connect to a "real' calliope on the hw simulator 
o possibly fake out events by having a timer on euterpe 
simulating the events that a calliope would generate. 

Since the meeting I have talked with Lisa R. about some of these 
solutions. It was calculated that the earliest that we would have 
IKOS cycles to run such a test would be about the middle of March 
and this would be about the time frame that we could have a 
calliope running on the IKOS too. This seemed like the best 
decision. 

02/15 By the time we are able to run this test on the HW simulator 
a iKOS-ready calliope will be available. No need for a fake 
calliope . 


Item: Create a microkernel that doesn't access calliope 
Who: sandeep 
Status: Done. 

02/15 The build target is kernel .nocalliope . 


Item: Build scripting/UI capabilities above gdb for regression tests. 
Who : doi 

Status : Punted . 

02/15 This item is deleted because it is no longer useful to track. 
When the time comes for us to run tests in a regression 
environment we will simply modify "regress 1 to do it for us. 


Software Simulator Status (left over from the 2/1 Meeting) 


Requests for additional terp functionality: 
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Reset (in test) 

X (uninitialized) values 

checkpoint /snapshot 

Hermes devices at all Hermes addresses 

Observe functionality of Cerberus bits (e.g. Hermes 

channel enable) 
Wrapping spaces (especially DRAM) 
"fake calliope" support 

holes in the address space, unimpl erne n ted Hermes channels 
to cause machine checks 
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From: 
Sent: 


tbr 


Thursday, February 16, 1995 11:43 PM 
'dickson (Richard Dickson)' 
'hopper'; 'ong' 
rf1r1w16wx64b 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Richard Dickson wrote (on Thu Feb 16): 
tim or mark, 

do either of you know if the data input bus to the exlax arrays 
within nb can be driven ful swing/vref instead of differential, 
just curoius 

I don't see why not, but it's a question for warren. 

warren, we are trying to reduce routing congestion by converting short 
busses from half swing differential to full swing plus vref. Do you 
forsee any problem doing this with the inputs to the exlax arrays 
in euterpe? 


Tim 
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From: 


tbr 


Sent: 


Friday, February 17, 1995 1:10 AM 


To: 


Cc: 


Subject: 


'vo' 

'geerf 

Makefile.tst 


Follow Up Flag: Follow up 
Flag Status: Red 


I checked in a new mnemo/Makefile.tst and a genpim2.pl, which now 
allows multiple GARDS_SUBDIRS variables along the lines of multiple 
exclude lists. 

If you define 

vo_GARDS_SUBDIRS_l = <whatever> 
vo_GARDS_SUBDIRS_2 = <whatever> 

to correspond to your exclude list, then you should be able to 

gmake vo_mnemogards 

and get what you expect, independent of anyone else's settings. 
The genpim2.pl currently only supports 4 of the blobks, but it should 
be obvious how to add more, and you do not need to edit it if you 
exclude some of them because the Makefile passes in the subdirs list. 

Let me know if you have a problem. 

(geert - in trying to make a euterpe .spivs deck for csyn I ran into 
the same problem because the BOM updated Makefile.tst to include you 
big list, so it would be worthwhile importing this same stuff into 
there . . .) 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Friday, February 17, 1995 1:10 AM 

'vo' 

'geert' 

Makefile.tst 


I checked in a new mnemo/Makef ile . tst and a genpim2.pl, which now allows multiple 
GARDS_SUBDIRS variables along the lines of multiple exclude lists. 

If you define 

vo_GARDS_SUBDIRS_l = < what ever > 
vo_GARDS_SUBD I RS_2 = < whatever > 

to correspond to your exclude list, then you should be able to 
gmake vo_mnemogards 

and get what you expect, independent of anyone else's settings. 

The genpim2.pl currently only supports 4 of the blobks, but it should be obvious how to 
add more, and you do not need to edit it if you exclude some of them because the Makefile 
passes in the subdirs list. 

Let me know if you have a problem. 

(geert - in trying to make a euterpe .spivs deck for csyn I ran into the same problem 
because the BOM updated Makefile.tst to include you big list, so it would be worthwhile 
importing this same stuff into there . . . ) 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisar (Lisa Robinson) 

Friday, February 17, 1995 9:05 AM 

'jeffm'; 'wood/ 

'billz'; 'dickson'; 'mws'; 'tbr' 

dcacheannoying 


The likedriverlog trace for the non-working ikos run is on rhodan 
/s3/euterpe/verilog/bsrc/res/16295 . 213 74 /results /dcacheannoying_0 . dpo 

The fabbing dump and log is on nosferatu /s2. 

I looked at the failing log and it the test seems to have almost finished. 

I created a parallel proteuszlib . edif 2 in proteus/verilog/zeblib that uses the bramz 
models (called bramzzlib . edif 2) and checked in a .parra.alt that uses the old bram while we 
are trying to understand the bramz 1 s . 

I have built a zycad simulator that uses the old models and am running dcacheannoying on 
it now. 


Lisa R. 
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From: lisar (Lisa Robinson) 

Sent: Friday, February 17, 1995 9:16 AM 

To: "doi"; 'jeffm' 

Cc: 'billz'; 'dickson'; 'mws'; 'tbr'; 'woody' 
Subject: Oh no! 

Out of logicsim .... 

Arithmetic exception (core dumped) 

Now I'm not using the bramz models this time! The core is 

lisar@nosferatu /s2/euterpe/verilog/bsrc 495 % Is -Is core 
9328 -rw-r-r-- 1 lisar 178671 84 Feb 17 07:05 core 

Lisa R. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 

Friday, February 17, 1995 10:11 AM 

'Kurt Wampler' 

'cadettes'; 'geert (Geert Rosseel)'; 'vo (Tom Vo)'; 'wingard (Drew Wingard)' 
Re: CSM dbu's? 


Kurt Wampler writes: 

In starting to look at converting the GARDS abstraction utilities to work with the CSM 
process, I've come across a fair amount of my code which was written with the implicit 
assumption that incoming Compass data is integer. In casual discussions with several 
people/ I've come to believe that we have quite a bit of code that was written with this 
assumption and will require rewriting in various ways to handle floating point incoming 
data . 

In some cases, it's not just as simple as converting variables from "int" 
to 

"double". A few examples: 

- The abgen program uses a bitmap-based compactor to consolidate obstruction 
data for GARDS . The X- and Y-coordinates of geometry are used to index 
bitmap arrays. The algorithm only works with integer X- and Y-coordinates. 

- We have a number of vlsimm scripts embedded in Makefiles/ shell- scripts 
which may produce erroneous results due to round- off errors; each one 
will have to be modified to magnify the incoming data sufficiently to 
integerize it. 

- The baseplate generation code uses the M4 preprocessor, which can't 
handle floating point numbers. 

It's beginning to look like we might spend quite a bit of time & effort sifting through 
all of these fixes before we're through. Perhaps more worrisome is that some of these 
tools/ scripts will break in a hidden fashion, producing erroneous results but not giving 
us a fatal error status; we could burn extra time tracking down latent round-off problems 
that don't come to light until very late in the design flow. 

I believe we could make this entire class of problem vanish by adopting an integer design 
unit equal to 0.1 micron. Even though some amount of hand layout has already been 
generated, I think it would be well worth it to convert it to 0.1-micron integer design 
units (and not difficult). I would like to propose that we make this change. 

Now I'll cower in my cubicle and await flaming darts, overripe fruit, etc. 
:-/ 

Seriously, comments anyone? 
- Kurt 

hopper writes : 

It does seem to me that the introduction of real numbers complicates things a bit. If we 
can avoid the complication through use of a scale factor of 10, and this allows many of 
our pre-existing tools to work with little modification then I'd say we should do it. 

I probably have a number of awk scripts and so forth the rumble of design data that would 
need to be taught about reals . I bet there are a bunch of other little scripts that we ' 11 
come across which would need tweaking, too. 

Dave- 

Does introducing a scale factor here mess things up for the technology files or for the 
mask folks? 


-thanks, 
hopper 
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From: hopper (Mark Hofmann) 

Sent: Friday, February 1 7, 1 995 1 0: 1 3 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'cadettes' 

Subject: Euterpe plot done 


Hi Geert, 

The plot of Euterpe with text and M2 is done and hanging up next to Tom 1 s cube . I only- 
made 1 copy- so you can have that one. If anyone wants a copy they can say: 

lpr -Phpplot -hoppe r/ compass /ho . euterpe 

- thanks , 
hopper 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Friday, February 17, 1995 11:27 AM 

'geert (Geert Rosseel)' 

dr 


Hi geert, 

I'm making another run at DR in 

~hopper/chip/euterpe/verilog/bsrc/dr/dr . pirn 
If you're curious you might see how it's going. The logfile will be called 

-hopper /chip/euterpe/verilog/bsrc/dr /out 
I think the right edge of the section will be at 445. 


-thanks , 
hopper 
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From: two (Fred Obermeier) 

Sent: Friday, February 17, 1995 1:49 PM 

To: 'hardheads' 

Cc: 'fwo' 

Subject: Csyn Euterpe BOM 229 errors 


Hi, 


Some of the csyn errors found in tbr_euterpe-passl . spivs generated from bsrc BOM 229.0 are 
listed below. The latest installed version of csyn now reports shorted differential 
inputs. Several differential input nodes, phi a/phi_b are still shorted. 

I will finish code improvements to the Exclusive Input Swing checks shortly so that the 
large number of false errors should go away. The new code is order independent and allows 
at least one half swing driver to appear anywhere among other fullswing drivers into 
half swing exclusive inputs. 

I'm building tbr_euterpe-passl . spivs based on bsrc BOM 2 31.0 now. 


Fred. 


error (Output Short Check . 1417 ) in file " tbr_euterpe-passl . spivs" : 
net has too many drivers 


topmost net : 

instance path: 
cellname path: 

drivers : 

instance path: 
cellname path: 
instance path: 
cellname path: 


top . atcimissvldrl2 
top .atcimissvldrl2 

top . xatucimssvldccrl2u0 . atcimissvldrl2 
top .xborf f 5df 8s . q_and0pf 

top . xatucimssvld2crl2u0 . atcimissvldrl2 
top . xborf f5df 8s . q_and0pf 


topmost net : 
instance path: 
cellname path: 

drivers : 

instance path: 
cellname path: 
instance path: 
cellname path: 


top . atcimissvldrl2_n 
top . atciraissvldrl2_n 

top . xatucimssvldccrl2u0 . atcimissvldrl2_n 
top .xborf f5df 8s . coadopt 

top . xatucimssvld2 crl2u0 . atcimissvldrl2_n 
top .xborf f5df 8s . q_ad0pf 


error (Ou tput Short Che ck . 1465 ) in file "tbr_euterpe -pas si . spivs " 
w/y drivers must have same swing 


topmost net : 

instance path: top . xgtlb .x2p_l . tail_vw_9 
cellname path: top.gtlb . tlbxrablk . tail_vw_9 
drivers : 

instance path: tlbxrablk .xlp_l .x37p_l .xl2p_l .x4p_l 

. tailvw 

cellname path: 

tlbxrablk. tlbxr74 col . tlbxr2col . tlb2crwlisws0 . tlb2crwlisw. tail_vw 
. . . many more tail_vw . . . 

instance path: tlbxrablk.xl85p_l 1 . tail_vw_9 

cellname path: tlbxrablk . gtisrcl . iout_xvw 

error (Output Short Check . 1449) in file " tbr_euterpe-passl . spivs" : 
drivers must have same num of collectors 


topmost net : 

instance path: top . xgtlb . x2p_l . tail_vw_l 

cellname path: top.gtlb . tlbxrablk. tail_vw_l 
drivers: 
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instance path: tlbxrablk. x2p_l . tail_vw_l 
cellname path: tlbxrablk. tlbvtailO . tail_vwy_l 

instance path: tlbxrablk . xlp_l .xlp_l .xlxlp_l .xl2p_l 

. x4p_l . tail_vw 

cellname path: 

tlbxrablk. tlbxr74 col . tlbxrScolsO . tlbxr8col . tlbrwliselsO . tlbrwlisel . tail_vw 
. . . many more tail_vw . . . 

. . . same for tail_vw_ 2 to 8 


error (Diff Input SwingCheck. 876) in file 
Differential inputs are shorted. 


" tbr_euterpe-passl . spivs" 


diff inputs shorted: 

master: scsmfl inst : xxlug_ctrldatag_db_7ag_q_7a_34p4p_l 
node name: phi_b2p2c 
node name : phi_a2p2 c 
paired drivers 

. . . lots of drivers . . . 
paired topmost nets 

instance path: top.phi_a2p 

instance path: top.phi_b2p 

cellname path: top.phi_a2p 

cellname path: top.phi_b2p 

All shorted phi nets: 

master: instance: nodes: 

scsmfl xxlug_ctrldatag_db_7ag_q_7a_0p4p_l phi_b2p2c phi_a2p2c 

scsmfl xxlug_ctrldatag_db_7ag_q_7a_100p4p_l phi_b2p2c phi_a2p2c 

scsmfl xxlug_ctrldatag_db_7ag_q_7a_101p4p_l phi_b2p2c phi_a2p2c 

scsmfl xxlug_ctrldatag_db_7ag_q_7a_102p4p__l phi_b2p2c phi_a2p2c 

scsmfl xxlug_ctrldatag_db_7ag_q_7a_103p4p_l phi_b2p2c phi_a2p2c 

scsmfl xxlug_ctrldatag_db_7ag_q_7a_104p4p_l phi_b2p2c phi_a2p2c 
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From: lisar (Lisa Robinson) 

Sent: Friday, February 17, 1995 2:24 PM 

To: 'dickson' 

Cc: 'woody'; 'billz'; 'tbr'; 'mws'; 'jeffm' 
Subject: Yeah! 

Summary file is res/1 7295. 17799/summary 


Design Name: c_euterpe_wrap 
Run Date: 17295 
Run ID: 17799 


Simulator: c_euterpe_wrap.mif.mm was built on Fri Feb 17 7:38:45 1995 

Using BOM: Version BOM,v 231.0 1995/02/16 10:54:44 LT woody 
Warning: Local BOM is out of date ... 
Log Message: 

Run started on host: nosferatu at: Fri Feb 17 07:47:39 PST 1995 
watchtes t_0 Processing watchtest_0 .... Ran ok 


Found PR 1977 of 17295.17799 filed with gnats so appending res/1 7295. 17799/summary with edit-pr 
Entering editpr ... 

Found: >Synopsis: c_euterpe_wrap BOM: 23 1 .0 regression run - ./l 7295. 17799 
Running the command: /bin/cat /tmp/summary » /tmp/ep21236 
edit-pr: filing regression/ 1977 back into the database 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Sandeep Nijhawan [sandeep@dolphin] 
Friday, February 17, 1995 3:46 PM 
'Loretta Guarino' 

, gmo@do!phin'; l gregg@dolphin'; 'khp@dolphin' 
Re: terp -disk-file 


Loretta Guarino wrote : 
> 

> Please give us some way to specify what name to use, though. 

> Otherwise, the regression scripts get all tangled up with one another. 
> 

Gregg and I had talked earlier as to the best way to do this for init files - 

The proposal is to have "virtual" file names which get xlated to a string that can 
be set by a command line option in the simulator. So e.g. the ukernel would open 
" /virtual /terp . f sO " instead of terp.fsO directly and the simulator would translate that to 
sim_disk_f ile if sim_disk_f ile was set using the --disk- file option otherwise translate it 
simply to terp.fsO. 
The init file would be similar. 

The terp command option could be something generic like 

- -xlate- virtual-name terp . f so : myapp , init : myinit 

but we could keep --disk-file around for the time being so reg scripts don't have to 
be changed right away. The ukernel will probably also first try to open something more 
appropriate such as " /virtual /app . 0 " instead of terp.fsO which was supposed to be a file 
system. 


Comments ? 


Sandeep 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Friday, February 17, 1995 5:41 PM 

'cadettes' 

'geeif; 'vo'; 'wingard' 
CSM dbu's? 


In starting to look at converting the GARDS abstraction utilities to work with the CSM 
process, I've come across a fair amount of my code which was written with the implicit 
assumption that incoming Compass data is integer. In casual discussions with several 
people, I've come to believe that we have quite a bit of code that was written with this 
assumption and will require rewriting in various ways to handle floating point incoming 
data. 

In some cases, it's not just as simple as converting variables from "int" 
to 

"double". A few examples: 

- The abgen program uses a bitmap-based compactor to consolidate obstruction 
data for GARDS. The X- and Y- coordinates of geometry are used to index 
bitmap arrays. The algorithm only works with integer X- and Y- coordinates . 

- We have a number of vlsimm scripts embedded in Makefiles/ shell -scripts 
which may produce erroneous results due to round-off errors; each one 
will have to be modified to magnify the incoming data sufficiently to 
integerize it. 

- The baseplate generation code uses the M4 preprocessor, which can't 
handle floating point numbers. 

It's beginning to look like we might spend quite a bit of time & effort sifting through 
all of these fixes before we're through. Perhaps more worrisome is that some of these 
tools/ scripts will break in a hidden fashion, producing erroneous results but not giving 
us a fatal error status; we could burn extra time tracking down latent round-off problems 
that don't come to light until very late in the design flow. 

I believe we could make this entire class of problem vanish by adopting an integer design 
unit equal to 0.1 micron. Even though some amount of hand layout has already been 
generated, I think it would be well worth it to convert it to 0.1-micron integer design 
units (and not difficult). I would like to propose that we make this change. 

Now I'll cower in my cubicle and await flaming darts, overripe fruit, etc. 
:-/ 

Seriously, comments anyone? 


- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


abbott 

Friday, February 17, 1995 6:04 PM 
'paulb (Paul Berry)' 
'gmo'; Vandyke' 
Engineering Spec 


Paul Berry wrote (on Fri Feb 17) : 

I've released a document that is the first draft for an engineering 
spec for the Pandora I (plain vanilla workstation with no Calliope) . 

p 15, Software: 

- you say PEXlib, Phigs . I don't know that those have been discussed, or would be 
particularly useful without a lot of work on our part to make them go fast . I.e., I think 
we should drop them. 

- also for C compiler you say "gcc with MU extns" . Our compiler is not a gcc derivative 
(we do have such a compiler but won't distribute it) . 

- we'll be distributing non-standard development tools, even on Pandora, such as the 
simulator, trace analysis tools (maybe just call it "tracetool" as a standin) , genperm, 
and maybe others (TBD) . These should probably get a separate section, and manpages. 


in the architecture section: 

- you say 1 GHz and 2 versions of Euterpe; probably worth mentioning that the CMOS version 
will operate slower. the current spec published by the design team is 4 00MHz. 

- in cpu.doc, under "Hermes protocol" you say it ' s a ring with "an initiator & up to 4 
targets". this is PCI terminology, which isn't necessarily appropriate; more important, 
it makes it sound like you can connect 5 devices, which isn't true. it's really a ring 
with 2 to 4 devices, one of which (Eu) is a master. 

- r.e. the CBI, what's with the "Atari game power supply"? I take it you're serious? 


in the mechanical section: 

- you're a real wizard with diagrams. how do you do that? 


- Curtis 
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From: jeffm (Jeff Marr) 
Sent: Friday, February 17, 1995 7:07 PM 
To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn* 
Subject: euterpe/verify/toplevel brmisstest.S 

Update of /p/cvsroot/euterpe/verify/toplevel 

In directory nosferatu:/N/auspex/root/s39/jeffm/chip/euterpe/verify/toplevel 

Modified Files: 

brmisstest.S 
Log Message: 
Fix V version 
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From: vo (Tom Vo) 

Sent: Friday, February 17, 1995 8:24 PM 
To: 'euterpe-checkins-disf; 'lisar*; 'tbr'; 'torn' 
Subject: euterpe/verilog/bsrc/ce cerberus.cpif 

Update of /p/cvsroot/euterpe/verilog/bsrc/ce 
In directory ghidra:/s5/vo/euterpe/verilog/bsrc/ce 

Modified Files: 

cerberus.cpif 
Log Message: 

moved cp ecl2cmos converters out of main cerberus region so 
there'd be half as many wires through the rhs choke point . 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 
Friday, February 17, 1995 10:13 PM 
•geeif; 'hopper'; 'tor 1 
Euterpe maze finished 


The Euterpe maze route finshed around 6:28PM this evening. 99.76% complete with only 619 
disconnects ! 3 3 (Down from 2,013 disconnects after maze routing of my Feb. 2 run.) That's 
significant progress. 

I'm going to see if I can call it up in REDIT here at home and have a look at how the 
datapath did after maze . . . 


- Kurt 
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From: wampler (Kurt Wampler) 

Sent: Friday, February 1 7, 1 995 1 1 :03 PM 

To: 'geert' 

Cc: 'hopper'; 'for' 

Subject: netcap file for maze result 

Geert - 

I've produced a netcap file for the maze-routed result: 

/n/godzi 1 1 a/s2/wampler/euroute/geert euterpe-iter. netcap 

I had forgotten to copy the ".xrf 1 file when I copied the ".dff' file, so 

I hope I used the right one in producing this report; I used the "old.xrf ' 

of Feb. 1 5 from your /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards directory. 

Routing completion in the datapath section looks very good. And in the random 
control logic areas above the datapath, there are just a couple of busses that 
stand out; perhaps candidates for early routing. If we can untangle that 
section just a little more, and solve the Cerberus/right-corridor blockage, we 
might be able to get down under 100 unroutes the next time around. 

The router does appear to have done some horizontal stitching in M2 in 
the datapath section; I'm curious to see whether any nets surface with 
unexpectedly high capacitance in that area. 

If we get down under 100 unroutes next time, we might consider firing up 
the batch rip-up router and seeing what it does. The 619 unroutes we have 
right now are still probably too many for it to handle, particularly since 
the majority of them will probably be beyond its ability to fix in the 
current placement. 

-Kurt 

(BTW - the next time you do a place/route, you might run the PGROUTE step for 
real so we can run the wire branch length verifier and expose anything we ought 
to be fixing for PG nets.) 
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From: vo (Tom Vo) 

Sent: Saturday, February 18, 1995 12:02 AM 
To: 'euterpe-checkins-dist'; 'lisar'; 'tor'; 'torn' 
Subject: euterpe/verilog/bsrc/ce cerberus.cpif 

Update of /p/cvsroot/euterpe/verilog/bsrc/ce 
In directory ghidra:/s5/vo/euterpe/verilog/bsrc/ce 

Modified Files: 

cerberus.cpif 
Log Message: 

move cp converters further apart . 
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From: woody (Jay Tomlinson) 

Sent: Saturday, February 18, 1995 1:41 AM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tor'; 'torn' 

Subject: euterpe/verilog/bsrc euterpe.V euterpe_wrap.V 

Update of /p/cvsroot/euterpe/verilog/bsrc 

In directory demeter:/N/auspex/root/s20/woody/chip/euterpe/verilog/bsrc 

Modified Files: 

euterpe.V euterpe_wrap.V 
Log Message: 

euterpe.V, cc: Added 'forward progress' logic to CC. 
After finishing a fill, CC will not start up processing for another cylinder 
until forward progess is detected for the cylinder that got the fill. This 
should fix the problem found by brmisstest. 

euterpe.V, uu: Added interface to CC to indicate forward progress. This is 
currently not accurate enough to work properly for microcoded or step 
junctions. 

euterpe wrap.V: added cc to default dump, removed ctiod. 

brmisstest_0 (from IBUF) run far enough to see that forward progess was being 
acheived. Also checked in undertow to see that CC was holding off other cylinders. 
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From: woody (Jay Tomlinson) 

Sent: Saturday, February 18, 1995 1:43 AM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verilog/bsrc/cc cchold.Veqn Makefile cc.V cc.ut ccstart.Veqn cctester.V 
Update of /p/cvsroot/euterpe/verilog/bsrc/cc 

In directory demeter:/N/auspex/root/s20/woody/ch ip/euterpe/verilog/bsrc/cc 

Modified Files: 

Makefile cc.V cc.ut ccstart.Veqn cctester.V 
Added Files: 

cchold.Veqn 
Log Message: 

euterpe.V, cc: Added 'forward progress' logic to CC. 
After finishing a fill, CC will not start up processing for another cylinder 
until forward progess is detected for the cylinder that got the fill. This 
should fix the problem found by brmisstest. 

euterpe.V, uu: Added interface to CC to indicate forward progress. This is 
currently not accurate enough to work properly for microcoded or step 
functions. 

euterpe_wrap.V: added cc to default dump, removed ctiod. 

brmisstest_0 (from IBUF) run far enough to see that forward progess was being 
acheived. Also checked in undertow to see that CC was holding off other cylinders. 
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From: woody (Jay Tomlinson) 

Sent: Saturday, February 18, 1995 1:44 AM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verilog/bsrc/uu genpim.pl pimlib.pl uu.V 

Update of /p/cvsroot/euterpe/verilog/bsrc/uu 

In directory demeter:/N/auspex/root/s20/woody/chip/euterpe/verilog/bsrc/uu 

Modified Files: 

genpim.pl pimlib.pl uu.V 
Log Message: 

euterpe.V, cc: Added 'forward progress' logic to CC. 
After finishing a fill, CC will not start up processing for another cylinder 
until forward progess is detected for the cylinder that got the fill. This 
should fix the problem found by brmisstest. 

euterpe.V, uu: Added interface to CC to indicate forward progress. This is 
currently not accurate enough to work properly for microcoded or step 
functions, some placement updates to seed more for the mincut. 

euterpe_wrap.V: added cc to default dump, removed ctiod. 

brmisstest_0 (from IBUF) run far enough to see that forward progess was being 
acheived. Also checked in undertow to see that CC was holding off other cylinders. 
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To: 


Cc: 


From: 


Sent: 


woody (Jay Tomlinson) 

Saturday, February 18, 1995 2:01 AM 

'doi'; lisar'; 'tor'; 'torn'; 'chip' 

'euterpe-checkins-dist' 


Subject: Release of BOMs by woody (euterpe) 

Checkin Message: 

euterpe.V, cc: Added 'forward progress' logic to CC. 
After finishing a fill, CC will not start up processing for another cylinder 
until forward progess is detected for the cylinder that got the fill. This 
should fix the problem found by brmisstest. 

euterpe.V, uu: Added interface to CC to indicate forward progress. This is 
currently not accurate enough to work properly for microcoded or step 
functions. 

euterpe_wrap.V: added cc to default dump, removed ctiod. 

brmisstest_0 (from IBUF) run far enough to see that forward progess was being 
acheived. Also checked in undertow to see that CC was holding off other cylinders. 

BOM Update in euterpe BOM 3.409 
BOM Update in euterpe/verilog BOM 3.323 
BOM Release in euterpe/verilog/bsrc BOM 232.0 
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From: lisar (Lisa Robinson) 
Sent: Saturday, February 18, 1995 10:53 AM 
To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr 1 ; 'woody' 
Subject: FYI: dcacheannoying 

Yesterday at 1 1 .20 I started up dcacheannoying from cold (nocheatreset) 
to see if I could reproduce the timing seem on the hw accelerators, ie 
there the test went to X but verilog with cheatreset but out of rom failed 
with one cylinder hanging. 

At 2:10 this morning the test did go to X. The dump and log are in /s2/euterpe/verilog/bsrc 
on nosferatu. 

Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Saturday, February 18, 1995 11:42 AM 
"Mark Hofmann' 

Vampler@cyclops.microunity.com'; 'cadettes'; 'geert (Geert Rosseel)'; 'vo (Tom Vo)'; 'wingard 
(Drew Wingard)'; Vanthof (Dave Van't Hof)' 
Re: CSM dbu's? 


Mark Hofmann writes: 


History: 

When the CSM design rules were handed out, I looked them over and found that CSM wanted 
their data in .1 micron resolution. In addition the design rule book was written with all 
numbers in .1 micron increments and to prevent massive numbers of layout errors from 
having the layout folks mutliply by 10 to get the drawing value, I used a .1 micron 
resolution. And yes, having to multiply by 10 may seem easy, but it will slow things down, 

>Kurt Wampler writes : 

>In starting to look at converting the GARDS abstraction utilities to 

>work 

with 

>the CSM process, I've come across a fair amount of my code which was 
written 

>with the implicit assumption that incoming Compass data is integer. In 
>casual discussions with several people, I've come to believe that we 
>have 
quite 

>a bit of code that was written with this assumption and will require 
rewriting 

>in various ways to handle floating point incoming data. 
> 

>In some cases, it's not just as simple as converting variables from "int" 
to 

> "double". A few examples: 
> 

> - The abgen program uses a bitmap -based compactor to consolidate 
obstruction 

> data for GARDS. The X- and Y- coordinates of geometry are used to 
index 

> bitmap arrays. The algorithm only works with integer X- and 
Y-coordinates . 

Multiply the incoming data by 10 for the CSM technology. 


> - We have a number of vlsimm scripts embedded in Makefiles/ shell -scripts 

> which may produce erroneous results due to round- off errors; each one 

> will have to be modified to magnify the incoming data sufficiently to 

> integerize it. 

I ' ve set up the drc environment to automatically change the ' inscale 1 
value 

based on the technology. This should be doable for baseplate generation as well. 
> 

> - The baseplate generation code uses the M4 preprocessor, which can't 

> handle floating point numbers. 

I'm really confused. I thought Geert already has some baseplate built. 


>It ' s beginning to look like we might spend quite a bit of time & effort 
sifting 

>through all of these fixes before we're through. Perhaps more 
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>worrisome 
is 

>that some of these tools/scripts will break in a hidden fashion, 
producing 

>erroneous results but not giving us a fatal error status; we could burn 
extra 

>time tracking down latent round-off problems that don't come to light 
until 

>very late in the design flow. 

I guess I have a concern that we have such limitations built in. When the 

CSM process was brought in and I started the technology file and drc flow generation, I 
did go through a small amount of work to fix my tools, but the tools are much better for 
it now. 


>I believe we could make this entire class of problem vanish by adopting 
an 

>integer design unit equal to 0 . 1 micron. Even though some amount of 
>hand layout has already been generated, I think it would be well worth 
>it to convert it to 0.1-micron integer design units (and not 
difficult) . I 
would 

>like to propose that we make this change. 
> 

>Now I'll cower in my cubicle and await flaming darts, overripe fruit, 
etc. :-/ 

> 

>Seriously, comments anyone? 
>- Kurt 

> 

>hopper writes: 

>lt does seem to me that the introduction of real numbers complicates 
things 

>a bit. If we can avoid the complication through use of a scale factor 
>of 10, and this allows many of our pre-existing tools to work with 
>little modification then I'd say we should do it. 

> 

>I probably have a number of awk scripts and so forth the rumble of 

>design data that would need to be taught about reals . I bet there are a 

>bunch of other little scripts that we'll come across which would need 

>tweaking, 

too . 

> 

>Dave- 

> Does introducing a scale factor here mess things up for the technology 
files 

>or for the mask folks? 
> 

> - thanks , 

> hopper 


It's doable. Every layout will need to be scaled. the drc flow will need to have every 
number changed (monotonous, but easy). It's best to do this in a coordinated fashion so 
as to confuse layout folks as little as possible. Then retraining of the layout folks is 
needed. Has anyone botherd to consult with any layout people? They are intimately 
involved here as well and should be involved in the final decision. 

The fact the a .1 micron resolution is being used for CSM has not been a secret so I'm 
confused about what has happened to bring up these concerns. 
Changing a 

few tools to be more flexible seems to be a better answer. 
Dave 
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Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 
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From: vanthof (vant) 

Sent: Saturday, February 18, 1995 12:01 PM 

To: 'hopper (Mark Hofmann)'; 'torn (Thomas Laidig)' 

Cc: 'vanthof (Dave Van't Hof)'; 'geert (Geert Rosseel)'; Vo (Tom Vo)'; 'lisar (Lisa Robinson)'; 'tbr 

(Tim B. Robinson)' 
Subject: euterpe Ivs shorts finished 


Hi, 

The euterpe lvs shorts test (all layers) is clean. The road is now open for an LVS 
run. A fullchip run may not be useful until a complete route is avaiable. 

The mnemo shorts run filled the disk, sigh. I've moved some files around and restarted 
it manually on mothra, but I'm afraid it will fail again. 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me , I didn ' t vote for him ! 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 18, 1995 2:18 PM 

'two (Fred Obermeier)' 

'fwo'; 'hardheads' 

Csyn Euterpe BOM 229 errors 


Fred Obermeier wrote (on Fri Feb 17) : 


Hi, 


Some of the csyn errors found in tbr_euterpe-passl . spivs generated from 
bsrc BOM 229.0 are listed below. The latest installed version of csyn 
now reports shorted differential inputs. Several differential input nodes, 
phi_a/phi_b are still shorted. 

As far as I know the phi_a/phi_b short should be fixed as a result of a release to an sc 
cell in proteus. The snapshot version was last updates Feb 14 at 22:58. If your netlist 
was compiled after that this problem should go away. 


Tim 
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From: 


tbr 


To: 


Cc: 

Subject: 


Sent: 


Saturday, February 18, 1995 3:08 PM 
'wampler (Kurt Wampler)' 
'geert'; 'hopper' 
Euterpe maze finished 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Fri Feb 17): 

The Euterpe maze route flnshed around 6:28PM this evening. 99.76% complete 
with only 619 disconnects!!! (Down from 2,013 disconnects after maze routing 
of my Feb.2 run.) That's significant progress. 

I'm going to see if I can call it up in REDIT here at home and have a look 
at how the datapath did after maze... 

Great stuff! 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 18, 1995 3:08 PM 

'warn pier (Kurt Wampler)' 

'geert'; 'hopper' 

Euterpe maze finished 


Kurt Wampler wrote (on Fri Feb 17) : 

The Euterpe maze route finshed around 6:28PM this evening. 99.76% complete 
with only 619 disconnects!!! (Down from 2,013 disconnects after maze routing 
of my Feb. 2 run.) That's significant progress. 

I'm going to see if I can call it up in RED IT here at home and have a look 
at how the datapath did after maze . . . 

Great stuff ! 


Tim 
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Sent: 


To: 


Subject: 


Cc: 


From: 


tbr 

Saturday, February 18, 1995 3:11 PM 

'wampler (Kurt Wampler)' 

'geert'; 'hopper' 

netcap file for maze result 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Fri Feb 17): 
Geert - 

I've produced a netcap file for the maze-routed result: 

/n/godzilla/s2/wampler/euroute/geert_euterpe-iter.netcap 

I had forgotten to copy the ".xrf ' file when I copied the ".dff ' file, so 

1 hope I used the right one in producing this report; I used the "old. xrf 

of Feb, 15 from your /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards directory. 

Routing completion in the datapath section looks very good. And in the random 
control logic areas above the datapath, there are just a couple of busses that 
stand out; perhaps candidates for early routing. If we can untangle that 
section just a little more, and solve the Cerberus/right-corridor blockage, we 
might be able to get down under 1 00 unroutes the next time around. 

1 think converting one or two of the short busses in that area to 
single ended, together with some placement improvements rich is 
finding should easily be able to get enough here. 

The router does appear to have done some horizontal stitching in M2 in 
the datapath section; I'm curious to see whether any nets surface with 
unexpectedly high capacitance in that area. 

Does that mean the M2 blockages at cell boundaries are not working as expected? 

If we get down under 100 unroutes next time, we might consider firing up 
the batch rip-up router and seeing what it does. The 619 unroutes we have 
right now are still probably too many for it to handle, particularly since 
the majority of them will probably be beyond its ability to fix in the 
current placement. 

Before then we need to look how bad the timing is on met's that have 
gone in with maze. Is there an easy way to get a "percentage over 
manhatten", say by comparing netcap and nof data? 


(BTW - the next time you do a place/route, you might run the PGROUTE step for 
real so we can run the wire branch length verifier and expose anything we ought 
to be fixing for PG nets.) 


-Kurt 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 18, 1995 3:11 PM 

'wampler (Kurt Wampler)' 

'geert'; 'hopper' 

netcap file for maze result 


Kurt Wampler wrote (on Fri Feb 17) : 
Geert - 

I've produced a netcap file for the maze-routed result: 

/n/godzilla/s2/wampler/euroute/geert_euterpe- iter .netcap 

I had forgotten to copy the " .xrf" file when I copied the ".dff" file, so 
I hope I used the right one in producing this report; I used the "old. xrf" 
of Feb. 15 from your /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards 
directory. 

Routing completion in the datapath section looks very good. And in the random 
control logic areas above the datapath, there are just a couple of busses that 
stand out; perhaps candidates for early routing. If we can untangle that 
section just a little more, and solve the Cerberus /right -corridor blockage, we 
might be able to get down under 10 0 unroutes the next time around. 

I think converting one or two of the short busses in that area to single ended, together 
with some placement improvements rich is finding should easily be able to get enough here. 

The router does appear to have done some horizontal stitching in M2 in 
the datapath section; I'm curious to see whether any nets surface with 
unexpectedly high capacitance in that area. 

Does that mean the M2 blockages at cell boundaries are not working as expected? 

If we get down under 10 0 unroutes next time, we might consider firing up 
the batch rip-up router and seeing what it does. The 619 unroutes we have 
right now are still probably too many for it to handle, particularly since 
the majority of them will probably be beyond its ability to fix in the 
current placement . 

Before then we need to look how bad the timing is on met 1 s that have gone in with maze . 
Is there an easy way to get a "percentage over manhatten" , say by comparing netcap and nof 
data? 


- Kurt 


(BTW - the next time you do a place/route, you might run the PGROUTE step for 
real so we can run the wire branch length verifier and expose anything we ought 
to be fixing for PG nets.) 


Tim 
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To: 


Cc: 


From: 


Sent: 


geert (Geert Rosseel) 

Saturday, February 18, 1995 3:29 PM 

'tbr'; 'wampler' 

'hopper' 


Subject: Re: netcap file for maze result 


> Before then we need to look how bad the timing is on met's that have 

> gone in with maze. Is there an easy way to get a "percentage over 

> manhatten", say by comparing netcap and nof data? 

I think that would be a great thing to have ... We have three files : 

geert_euterpe-base.netcap : used for initial power settings for 
"non-i/o " cells 

geert_euterpe- iter. nof : used for inital power settings for 
sub-blocks I/O cells 

geert_euterpe-iter.netcap : final routing result 

I'm anot sure how we want to compare the data of these three files, 
but just comparing the last two would be a good start. 


Geert 
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From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Saturday, February 18, 1995 3:32 PM 

'geert (Geert Rosseel)' 

'hopper'; 'wampler 1 

Re: netcap file for maze result 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Feb 18): 


> Before then we need to look how bad the timing is on met's that have 

> gone in with maze. Is there an easy way to get a "percentage over 

> manhatten", say by comparing netcap and nof data? 

I think that would be a great thing to have ... We have three files : 

geert_euterpe-base.netcap : used for initial power settings for 
"non-i/o " cells 

geert_euterpe-iter.nof : used for inital power settings for 
sub-blocks I/O cells 

geert_euterpe-iter.netcap : final routing result 

I'm anot sure how we want to compare the data of these three files, 
but just comparing the last two would be a good start. 

The most interseting would be comparing the assumption going into the 
topt run prior to the route with the final .netcap result. I assume 
the input is a combination of the first two files, with netcap data 
taking precedence if available. 


Tim 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 18, 1995 3:32 PM 

'geert (Geert Rosseel)' 

•hopper'; 'wampler' 

Re: netcap file for maze result 


Geert Rosseel wrote (on Sat Feb 18) : 


> Before then we need to look how bad the timing is on met 1 s that have 

> gone in with maze. Is there an easy way to get a "percentage over 

> manhatten" , say by comparing netcap and nof data? 

I think that would be a great thing to have ... We have three files : 

geert_euterpe-base. netcap : used for initial power settings for 
"non-i/o " cells 

geert_euterpe- iter . nof : used for inital power settings for 
sub-blocks I/O cells 

geert_euterpe-iter. netcap : final routing result 

I'm anot sure how we want to compare the data of these three files, 
but just comparing the last two would be a good start. 

The most inter set ing would be comparing the assumption going into the topt run prior to 
the route with the final .netcap result. I assume the input is a combination of the first 
two files, with netcap data taking precedence if available. 


Tim 
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From: warn pier (Kurt Wampler) 

Sent: Saturday, February 18, 1995 3:56 PM 

To: 'tbr' 

Cc: 'geert'; 'hopper' 

Subject: Re: netcap file for maze result 


@ wampler writes : 
© 

@ The router does appear to have done some horizontal stitching in M2 in 
® the datapath section; I'm curious to see whether any nets surface with 
@ unexpectedly high capacitance in that area. 
© 

@tbr queries: 
@ 

©Does that mean the M2 blockages at cell boundaries are not working as expected? 

The M2 blockages at cell boundaries are definitely working, but I may have 
seen some instances where M4 was quite dense and M2 was sparse, and the 
router went on M2 until it found one of these obstructions, found a way 
over it, and then dropped back down to M2, perhaps doing this several 
times. I hope that doesn't happen too often. 

©Before then we need to look how bad the timing is on met ' s that have ©gone in with maze. 
Is there an easy way to get a "percentage over ©manhatten" , say by comparing netcap and 
nof data? 

©Geert replies: 
© 

© I think that would be a great thing to have ... We have three files : 

© 

© geert_euterpe - base . netcap : used for initial power settings for 

© "non-i/o " cells 

© 

© geert_euterpe- iter .nof : used for inital power settings for 
© sub-blocks I/O cells 

© 

© geert_euterpe- iter .netcap : final routing result 
© 

© I'm anot sure how we want to compare the data of these three files, @ but just 
comparing the last two would be a good start. 

©tbr responds: 

© 

©The most inter set ing would be comparing the assumption going into the @topt run prior to 
the route with the final .netcap result. I assume ©the input is a combination of the 
first two files, with netcap data ©taking precedence if available. 

Perhaps one way to collate this analysis would be to examine the ratio 
between actual capacitance and estimated capacitance, discard any where 
the ratio is 1.0 or less, and sort in descending order by ratio? 

- Kurt 
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From: lisar (Lisa Robinson) 
Sent: Saturday, February 18, 1995 5:08 PM 
To: 'billz'; 'dickson'; 'jeffm'; 'mws 1 ; 'tbr'; 'woody' 
Subject: Where reset goes away ... 

This is the timing of reset going away in the h/w simulation 
and in verilog is cheatreset is not used: 


U U U U LI Phi 


I | sc 


I reset 


With cheatreset set it was 


U U U U U Phi 


sc 


reset 


I have changed euterpe_wrap to reflect the upper 

as a default when cheatreset is true but added a parameter 

that can be passed to the simulation SKEWWRTOCERB that 

skews the point at which reset goes away by SKEWWRTOCERB sofa clocks. 

1 re-ran uncrupt2 with the now default timing and now 
it too hangs in verilog just as it did on the ikos. 
The dump is in /s2/euterpe/verilog/bsrc on 
nosferatu. 

I'll defer to tbr to and warren to figure out how to 
handle this on the tester. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


lisar (Lisa Robinson) 

Saturday, February 18, 1995 5:19 PM 

'warren' 

'euterpe' 

Euterpe out of reset 


Mark 


Euterpe comes out of reset at some point with respect to the cerberus clock SC. Depending 
upon the process, temperature etc that point may vary. Because the sofa clock is about 5 0 
times faster than the cerberus clock this variation may mean that the timing of the first 
transactions which are either to the rom or cerberus (ie clocked off of SC) could be 
different. 

This difference can result in large changes in the way the cylinders interact. 


Lisa R. 
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From: tbr 

Sent: Saturday, February 18, 1995 5:21 PM 

To: 'warren' 

Subject: forwarded message from Lisa Robinson 

Follow Up Flag: Follow up 
Flag Status: Red 

Just in case you got missed on this one. 

Start of forwarded message 

Return-Path: <lisar> 

Received: from nosferatu.microunity.com by gaea.microunity.com (4.1 /muse 1.3) 

id AA21952; Sat, 18 Feb 95 15:07:35 PST 
Received: from localhost by nosferatu.microunity.com (8.6.4/muse-sw.3) 

id PAA09406; Sat, 18 Feb 1995 15:07:34 -0800 
Message-Id: <1 99502 1 82307.PAA09406@nosferato.microunity.com> 
From: lisar (Lisa Robinson) 
To: billz, dickson, jeffm, mws, tbr, woody 
Subject: Where reset goes away ... 
Date: Sat, 18 Feb 1995 15:07:34 -0800 


This is the timing of reset going away in the h/w simulation 
and in verilog is cheatreset is not used: 


U U U U U Phi 

"1Z ZZ\ sc 


With cheatreset set it was 


U U U U U Phi 

HZ i sc 


reset 


I have changed euterpe_wrap to reflect the upper 

as a default when cheatreset is true but added a parameter 

that can be passed to the simulation SKEWWRTOCERB that 

skews the point at which reset goes away by SKEWWRTOCERB sofa clocks. 

I re-ran uncrupt2 with the now default timing and now 
it too hangs in verilog just as it did on the ikos. 
The dump is in /s2/euterpe/verilog/bsrc on 


Exhibit Cll 


Page 373 of 559 


nosferatu. 

I'll defer to tbr to and warren to figure out how to 

handle this on the tester. 

End of forwarded message 
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From: dickson (Richard Dickson) 

Sent: Saturday, February 18, 1995 9:21 PM 

To: 'geert'; 'hopper'; 'tbr' 

Subject: gplace core dump 

you'all 

a gards job i was just running core dumped. 

HOME=/ri/rama/s5/dickson/euterpe/tools LMJLICENSEJFILE=/n/rama/s5/dickson/eute 
rpe/tools/sl/license/license.dat DISPLAY=demeter:0 SLJTOTAL_DURATION=500 CHIPROO 
TVn/rama/s5/dickson/euterpe /n/rama/s5/dickson/euterpe/tools/sl/bin/invoke gpla 
ce sr-pass3 -listing sr-pass3.gplace.lis -cmdin sr-pass3 . gplace. nic -colorin sr- 
pass3.gplace.mobi234 -inbat 1 

Requires a minimum license of xgplacel_3 or gards 1_3 . 
Applicable licenses available at your installation : 

gardsconfig_3 
Checked out one user token of a gardsconfig_3 license. 

Segmentation fault (core dumped) 

gmake[2]: *** [gards/sr-pass3.gplace.lis] Error 11 

gmake[2]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/sr' 
gmakefl]; *** [sr-base.netcap] Error 1 

rm sr_eventl 6,esp sr_inc4.esp sr_cla.esp srjnc4a.esp sr_mchold.esp 
gmakefl]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/sr' 
gmake: *** [srgards] Error 1 
page queued 
starting paged 


any of you had similar problems ? 

dickson 
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From: 


tbr 


To: 

Cc: 

Subject: 


Sent: 


Saturday, February 18, 1995 9:23 PM 
'dickson (Richard Dickson)' 
'geert'; 'hopper' 
gplace core dump 


Follow Up Flag: Follow up 
Flag Status: Red 

Rich, we were having a lot of trouble with rama not exporting 
things properly. A lot of machines could not see /n/tmp and there 
were other problems. We rebotted it about 10 mins ago. Sorry if it 
clobbered you, but things were pretty sick, so we decided to do it 
right away. Let me know if you have any more trouble. 


Richard Dickson wrote (on Sat Feb 1 8): 
you'all 

a gards job i was just running core dumped. 

HOME=/n/rama/s5/dickson/euteipe/tools LM_LlCENSE_FILE=/n/rama/s5/dickson/eute 
rpe/tools/siyiicense/license.dat DISPLAY=demeter:0 SL_TOTAL_DURATION=500 CHIPROO 
T=/n/rama/s5/di ckson/euterpe /n/rama/s5/dickson/euterpe/tool s/s 1/b i n/in voke gpl a 
ce sr-pass3 -listing sr-pass3 .gplace. lis -cmdin sr-pass3.gplace.nic -colorin sr- 
pass3.gplace.mobi234 -inbat 1 

Requires a minimum license of xgplacel_3 or gards 1_3 . 
Applicable licenses available at your installation : 

gardsconfig_3 
Checked out one user token of a gardsconfig_3 license. 

Segmentation fault (core dumped) 

gmake[2]: *** [gards/sr-pass3.gplace.lis] Error 1 1 

gmake[2]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/sr' 
gmakejl]: *** [sr-base.netcap] Error 1 

rm sr_event!6.esp sr _inc4.esp sr_cla.esp sr_inc4a.esp sr_mchold.esp 
gmake[l]: Leaving directory '/N/rama/root/sS/dickson/euterpe/verilog/bsrc/sr' 
gmake: *** [srgards] Error 1 
page queued 
starting paged 


any of you had similar problems ? 


Tim 


dickson 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Sunday, February 19, 1995 9:59 AM 
'dbulfer (David Bulfer)' 
'pandora' 

The Cerberus bus and the PCI/Hermes/Hestia l/F 


Follow Up Flag: Follow up 
Flag Status: Red 

David Bulfer wrote (on Fri Jan 27): 

A couple of wees ago I raised the question about if and how to connect 
to the Cerberus bus of a PCI/Hermes/Hestia I/F board that can be 
plugged into any PCI-based computer (Pandora or a PC). While Tim and 
I discussed it, there has been no closure. 

The assumption is that Cerberus should be available in a development 
environment for download and debug. Even in the special case of 
Pandora where we could route the main processors Cerberus bus, there 
are no available pins on the PCI connector. In the general case of a 
PC, the signals do not exist. The only likely scenario is to use the 
PCI bus I/F in Mnemo. 

Mnemo would have PCI slave registers for command/address and data. 
Presumably, any PCI master could download program data or interrogate 
status of a the Hestia development unit. 

Comments? 

I think this is still on the open list. Craig has been doing some 
thinking about this in the context of Pandora at least, and observed 
that a minor feature we had not fully implemented in Euterpe would go 
a long way to help here. We have been trying to get this feature 
completed since it is only requires a change in the Cerberus CMOS area 
which should have no impact on the rest of Euterpe. (However, at this 
point it's not completed.) 

The idea is that if the Cerberus address of the Euterpe is 0, then any 
read to a Cerberus address bigger than 64 (octlet address), would 
actually read the ROM at the corresponding address. If the Cerberus 
address is non-zero, then this feature is disabled. It is already the 
case that Euterpe uses the Cerberus address to control whether the 
initial code fetch is from the ROM space or from Cerberus space. 
Thus, in a system which has two processors, one in Pandora and one in 
Hestia, we could set the Cerberus address of the Euterpe in Pandora to 
be 0 and for the one in the Hestia to be non-zero (we have pin on the 
expansion connector to force that). Then, the Pandora would act as 
normal, booting directly from its ROM, whereas the processor in Hestia 
would boot from Cerberus, which in turn would fetch code from the 
Pandora ROM, 

By looking at the PC, it's easy for the code to tell which case we 

have (there is no direct way to interrogate the Cerberus address), so 

the ROM could be programmed to take a branch in the case that the code 
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is being accessed via Cerberus from the remote processor. This in 
turn allows a separate image to be programmed into the Pandora flash 
ROM, as an experimental boot for the Hestia. Now, the ROM is bigger 
than the Cerberus address space of a single Cerberus device, so only 
a portion of the ROM is actually accessible in this way, but probably 
far more than we actually need for a boot. 

So, the net effect of this is that we only need a single Cerberus in 

the combined system, and we need no code initially programmed into the 

flash ROM on Hestia. 

Now, let's go back to the case you actually raise, of a PC based 
system with a Mnemosyne PCK->Hermes interface card. We have the 
Mnemosyne on that card attached to the Cerberus of the Hestia, but we 
do not have any control of the Cerberus from the PC side. While we 
could implement a full blown Cerberus master in Mnemosye and wire it 
off in the case it is a memory controller, I'm cencemed about doing 
that because the chip is getting full, and our schedule assumes we 
have plenty of free space and so an easy place and route job. In 
addition to the master function, in order to get the same ROM 
emulation we would have in the Pandora system above we would need to 
add either a ROM interface (for which we have no pins), some on chip 
memory (probably RAM) which could be downloaded from the PCI bus, or 
an interface into the PCI master interface so we could actually fetch 
code rom somewhere else in the PCI address space (eg from the buffer 
memory in the Mnemosyne itself). All of these seem to add a lot of 
complexity. 

However, for other reasons we have already decided we need (though 
have not yet scheduled the implementation of) an ISA Cerberus 
interface. If we had such a card, then clearly we could just add that 
to the PC system in question and we have everything we need. Such a 
card would (presumably) be using an FPGA type component to implement 
the interface and would likely have plenty of pins to directly add a 
flash ROM, which could be mapped to appear exactly the same way as the 
Pandora ROM would to the remote Hestia system. 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, February 19, 1995 9:59 AM 

*d bulfer (David Bulfer)' 

'pandora' 

The Cerberus bus and the PCI/Hermes/Hestia l/F 


David Bulfer wrote {on Fri Jan 27) : 

A couple of wees ago I raised the question about if and how to connect 
to the Cerberus bus of a PCI/Hermes/Hestia I/F board that can be 
plugged into any PCI -based computer (Pandora or a PC) . While Tim and 
I discussed it, there has been no closure. 

The assumption is that Cerberus should be available in a development 
environment for download and debug. Even in the special case of 
Pandora where we could route the main processors Cerberus bus, there 
are no available pins on the PCI connector. In the general case of a 
PC, the signals do not exist. The only likely scenario is to use the 
PCI bus I/F in Mnemo. 

Mnemo would have PCI slave registers for command/ address and data. 
Presumably, any PCI master could download program data or interrogate 
status of a the Hestia development unit. 


I think this is still on the open list. Craig has been doing some thinking about this in 
the context of Pandora at least, and observed that a minor feature we had not fully 
implemented in Euterpe would go a long way to help here . We have been trying to get this 
feature completed since it is only requires a change in the Cerberus CMOS area which 
should have no impact on the rest of Euterpe. (However, at this point it's not 
completed. ) 

The idea is that if the Cerberus address of the Euterpe is 0, then any read to a Cerberus 
address bigger than 64 (octlet address) , would actually read the ROM at the corresponding 
address. If the Cerberus address is non-zero, then this feature is disabled. It is 
already the case that Euterpe uses the Cerberus address to control whether the initial 
code fetch is from the ROM space or from Cerberus space. 

Thus, in a system which has two processors, one in Pandora and one in Hestia, we could set 
the Cerberus address of the Euterpe in Pandora to be 0 and for the one in the Hestia to be 
non-zero (we have pin on the expansion connector to force that) . Then, the Pandora would 
act as normal, booting directly from its ROM, whereas the processor in Hestia would boot 
from Cerberus, which in turn would fetch code from the Pandora ROM. 

By looking at the PC, it's easy for the code to tell which case we have (there is no 
direct way to interrogate the Cerberus address) , so the ROM could be programmed to take a 
branch in the case that the code is being accessed via Cerberus from the remote processor. 
This in turn allows a separate image to be programmed into the Pandora flash ROM, as an 
experimental boot for the Hestia. Now, the ROM is bigger than the Cerberus address space 
of a single Cerberus device, so only a portion of the ROM is actually accessible in this 
way, but probably far more than we actually need for a boot. 

So, the net effect of this is that we only need a single Cerberus in the combined system, 
and we need no code initially programmed into the flash ROM on Hestia. 

Now, let's go back to the case you actually raise, of a PC based system with a Mnemosyne 
PCl<->Hermes interface card. We have the Mnemosyne on that card attached to the Cerberus 
of the Hestia, but we do not have any control of the Cerberus from the PC side. While we 
could implement a full blown Cerberus master in Mnemo sye and wire it off in the case it is 
a memory controller, I'm cencerned about doing that because the chip is getting full, and 
our schedule assumes we have plenty of free space and so an easy place and route job. In 
addition to the master function, in order to get the same ROM emulation we would have in 
the Pandora system above we would need to add either a ROM interface (for which we have no 
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pins) , some on chip memory (probably RAM) which could be downloaded from the PCI bus, or 
an interface into the PCI master interface so we could actually fetch code rom somewhere 
else in the PCI address space (eg from the buffer memory in the Mnemosyne itself). All of 
these seem to add a lot of complexity. 

However, for other reasons we have already decided we need (though have not yet scheduled 
the implementation of) an ISA Cerberus interface. If we had such a card, then clearly we 
could just add that to the PC system in question and we have everything we need. Such a 
card would (presumably) be using an FPGA type component to implement the interface and 
would likely have plenty of pins to directly add a flash ROM , which could be mapped to 
appear exactly the same way as the Pandora ROM would to the remote Hestia system. 

Tim 
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From: 


tbr 


To: 


Cc: 


Subject: 


Sent: 


Sunday, February 19, 1995 11:02 AM 
'abbotf 

'dickson'; 'mws'; 'craig' 
average instructions 


Follow Up Flag: Follow up 
Flag Status: Red 


We (craig, rich, mark, myself) have done some thinking on these, but 
the result is I still hold the position we should not be trying to get 
them into this implementation of Euterpe. 

We looked at a few possible approaches, but each has trouble without 
significant changes to what we have now. 

First, I'm assuming that since the goal is to save issue slots, 
implementations that take multiple slots are not worth considering. 
As to latency, 1 don't think you had expressed hard requirements 
there, so we looked at what we could do if we assumed all the stages 
of the main pipe would be available if needed. Roughly, these 
correspond to add, XLU (ie shift), and add respectively (assuming we 
are only using the fmal CLA in the multiplier section). At first 
sight this looks like just what we need to do the basic add, shift 
right, then a fanal add to propagate the rounding increment if needed. 

However, there is a major flaw in that the final CLA in stage 3 is 
only 64 bits wide because for multiplies we have multiple issue slots, 
so using this for the rounding is ruled out by our basic assumption of 
the requirement for single slot issue for group versions of these ops. 
Second, since the point of the instructions is to preserve the upper 
bit (or bits in the group case with < 64 bit operands), we would have 
to feed more than 128 bits (9 bits per byte given 8 bits is the 
smallest arithmentic size we support) from the adder to the XLU. We 
don't have those paths. So, even if we abandon the rounding add in 
the third stage and assume you use some statically selected 
combination of A+B and A+B+l type operations to remove the bias, we 
still can't preserve the upper bit information I assume you want. 
I think when we were talking, I had assumed that there may be an easy 
way to preserve this information within the adder since the carries 
are there as part of the overflow checking, but rich does not see an 
easy way to get this out without a significant change. 

Craig felt that the only real option without a major overhaul of the 
data path is to do either 7 bit or 15 bit arithemetic, so the upper 
bit is available to catch the overflow. (I'm not sure how that would 
work out in the case of signed arithmetic.) Craig also felt that the 
best way to tackle this class of operations in a future implementation 
would be to shift the operands right on the way in (rather than the 
result on the way out), and do a calculation on the side on the low 
order bits to control the the carry in to get the rounding effect. 
The carry in is not needed till a later stage of the carry look ahead, 
so there should be time to do this. In this way, the whole thing 
would be accomplished in the first pipe stage (ie latency 1). 
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However, we do not have this option in the current implementation 
since there is just not time in the path to squeeze in the extra 
logic. It would either involve a doubling of the size of the bypass 
muxes and associated control, or a doubling of the initial 
propagate/generate terms in the adder to bring in either the operand, 
or the operand shifted, neither of which is tractable. 

So, my recommendation is that we decide what set of operations we 
really want in the absense of the immendiate implementation 
constraints and get those added to the architectural definition even 
though they will be in the class of un implemented instructions in the 
current Euterpe. Then, we can consider them as possible candidates 
for inclusion in the new XDP implementation in Cronus (since it's a 
whole new custom design anyway). (In passing I note that just this 
week, we got the Euterpe datapath to route to completion for the first 
time and we are now at 99.7% for the chip as a whole.) 

Tim 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, February 19, 1995 11:02 AM 

•abbott' 


Subject: 


'dickson'; 'mws'; 'craig' 
average instructions 


We (craig, rich, mark, myself) have done some thinking on these, but the result is I still 
hold the position we should not be trying to get them into this implementation of Euterpe. 

We looked at a few possible approaches, but each has trouble without significant changes 
to what we have now. 

First, I'm assuming that since the goal is to save issue slots, implementations that take 
multiple slots are not worth considering. 

As to latency, I don't think you had expressed hard requirements there, so we looked at 
what we could do if we assumed all the stages of the main pipe would be available if 
needed. Roughly, these correspond to add, XLU (ie shift) , and add respectively (assuming 
we are only using the final CLA in the multiplier section) . At first sight this looks 
like just what we need to do the basic add, shift right, then a fanal add to propagate the 
rounding increment if needed. 

However, there is a major flaw in that the final CLA in stage 3 is only 64 bits wide 
because for multiplies we have multiple issue slots, so using this for the rounding is 
ruled out by our basic assumption of the requirement for single slot issue for group 
versions of these ops . 

Second, since the point of the instructions is to preserve the upper bit (or bits in the 
group case with < 64 bit operands) , we would have to feed more than 12 8 bits (9 bits per 
byte given 8 bits is the smallest arithmentic size we support) from the adder to the XLU. 
We don't have those paths. So, even if we abandon the rounding add in the third stage and 
assume you use some statically selected combination of A+B and A+B+l type operations to 
remove the bias, we still can't preserve the upper bit information I assume you want. 
I think when we were talking, I had assumed that there may be an easy way to preserve this 
information within the adder since the carries are there as part of the overflow checking, 
but rich does not see an easy way to get this out without a significant change. 

Craig felt that the only real option without a major overhaul of the data path is to do 
either 7 bit or 15 bit arithemetic, so the upper bit is available to catch the overflow. 
(I'm not sure how that would work out in the case of signed arithmetic.) Craig also felt 
that the best way to tackle this class of operations in a future implementation would be 
to shift the operands right on the way in (rather than the result on the way out) , and do 
a calculation on the side on the low order bits to control the the carry in to get the 
rounding effect. 

The carry in is not needed till a later stage of the carry look ahead, so there should be 
time to do this. In this way, the whole thing would be accomplished in the first pipe 
stage (ie latency 1) . 

However, we do not have this option in the current implementation since there is just not 
time in the path to squeeze in the extra logic. It would either involve a doubling of the 
size of the bypass muxes and associated control, or a doubling of the initial 
propagate /generate terms in the adder to bring in either the operand, or the operand 
shifted, neither of which is tractable. 

So, my recommendation is that we decide what set of operations we really want in the 
absense of the immendiate implementation constraints and get those added to the 
architectural definition even though they will be in the class of unimplemented 
instructions in the current Euterpe. Then, we can consider them as possible candidates 
for inclusion in the new XDP implementation in Cronus (since it's a whole new custom 
design anyway) . (In passing I note that just this week, we got the Euterpe datapath to 
route to completion for the first time and we are now at 99.7% for the chip as a whole.) 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 
Sunday, February 19, 1995 6:49 PM 
Tim B. Robinson' 

'craig@tallis'; 'dickson@tallis'; , mws@tallis , 
average instructions 


Tim B. Robinson wrote (on Sun Feb 19) : 

I think when we were talking / I had assumed that there may be an easy 
way to preserve this information within the adder since the carries 
are there as part of the overflow checking, but rich does not see an 
easy way to get this out without a significant change. 

Ok, that's the key point for (or rather, against) the feasibility of a quick & dirty 
insertion of the non-rounding average instructions. 

Craig felt that the only real option without a major overhaul of the 
data path is to do either 7 bit or 15 bit arithemetic, so the upper 
bit is available to catch the overflow. (I'm not sure how that would 
work out in the case of signed arithmetic.) Craig also felt that the 
best way to tackle this class of operations in a future implementation 
would be to shift the operands right on the way in (rather than the 
result on the way out) , and do a calculation on the side on the low 
order bits to control the the carry in to get the rounding effect. 

I assume this means the l.o. bit that was shifted right is included in the calculation on 
the side. If so, it sounds fine to me. 


So, my recommendation is that we decide what set of operations we 
really want in the absense of the immendiate implementation 
constraints and get those added to the architectural definition even 
though they will be in the class of unimplemented instructions in the 
current Euterpe. Then, we can consider them as possible candidates 
for inclusion in the new XDP implementation in Cronus (since it's a 
whole new custom design anyway) . (In passing I note that just this 

Well, let me know when's a good time to bring it up in regards to Cronus. 

week, we got the Euterpe datapath to route to completion for the first 
time and we are now at 99.7% for the chip as a whole.) 

Glad to hear it! 


- Curtis 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Sunday, February 19, 1995 6:55 PM 
'Curtis Abbott' 

'craig@tallis'; 'dickson@tallis'; 'mws@tallis' 
average instructions 


Follow Up Flag: Follow up 
Flag Status: Red 


Curtis Abbott wrote (on Sun Feb 19): 

Craig felt that the only real option without a major overhaul of the 
data path is to do either 7 bit or 1 5 bit arithemetic, so the upper 
bit is available to catch the overflow. (I'm not sure how that would 
work out in the case of signed arithmetic.) Craig also felt that the 
best way to tackle this class of operations in a future implementation 
would be to shift the operands right on the way in (rather than the 
result on the way out), and do a calculation on the side on the low 
order bits to control the the carry in to get the rounding effect. 

I assume this means the l.o. bit that was shifted right is included in 
the calculation on the side. If so, it sounds fine to me. 

Yes, by shifting first, the adder itself would not need greater width, 
two low order bits from each of the operands would be peeled off to 
calculate the carry in in each slice of the datapath. 


So, my recommendation is that we decide what set of operations we 
really want in the absense of the immendiate implementation 
constraints and get those added to the architectural definition even 
though they will be in the class of unimplemented instructions in the 
current Euterpe. Then, we can consider them as possible candidates 
for inclusion in the new XDP implementation in Cronus (since it's a 
whole new custom design anyway). (In passing I note that just this 

Well, let me know when's a good time to bring it up in regards to 
Cronus. 

Now! Geert needs to be in the loop. Serious work on the XDP is 
scheduled to start in about a week I think. 

week, we got the Euterpe datapath to route to completion for the first 
time and we are now at 99.7% for the chip as a whole.) 

Glad to hear it! 

It's looking good. We have one last area of congestion which we are 
working on now, and there does not seem to be any reason why we can't 
fix it (selective conversion of short busses to single ended, 
placement improvements). Once we have a version fully routed we need 
an iteration to fix the remaining timing viloations. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@tallis] 
Sunday, February 19, 1995 6:55 PM 
'Curtis Abbott' 

'craig@tal!is'; 'dickson@talfis'; 'mws@tallis' 
average instructions 


Curtis Abbott wrote (on Sun Feb 19) : 

Craig felt that the only real option without a major overhaul of the 
data path is to do either 7 bit or 15 bit arithemetic, so the upper 
bit is available to catch the overflow. (I'm not sure how that would 
work out in the case of signed arithmetic.) Craig also felt that the 
best way to tackle this class of operations in a future implementation 
would be to shift the operands right on the way in (rather than the 
result on the way out) , and do a calculation on the side on the low 
order bits to control the the carry in to get the rounding effect. 

I assume this means the l.o. bit that was shifted right is included in 
the calculation on the side. If so, it sounds fine to me. 

Yes, by shifting first, the adder itself would not need greater width. 

two low order bits from each of the operands would be peeled off to calculate the carry in 
in each slice of the datapath. 


So, my recommendation is that we decide what set of operations we 
really want in the absense of the immendiate implementation 
constraints and get those added to the architectural definition even 
though they will be in the class of unimplemented instructions in the 
current Euterpe. Then, we can consider them as possible candidates 
for inclusion in the new XDP implementation in Cronus (since it's a 
whole new custom design anyway) . (In passing I note that just this 

Well, let me know when's a good time to bring it up in regards to 
Cronus . 

Now! Geert needs to be in the loop. Serious work on the XDP is scheduled to start in 
about a week I think. 

week, we got the Euterpe datapath to route to completion for the first 
time and we are now at 99.7% for the chip as a whole.) 

Glad to hear it ! 

It's looking good. We have one last area of congestion which we are working on now, and 
there does not seem to be any reason why we can't fix it (selective conversion of short 
busses to single ended, placement improvements) . Once we have a version fully routed we 
need an iteration to fix the remaining timing viloations. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Sunday, February 19, 1995 7:41 PM 

To: 'brian'; 'woody' 

Cc: 'jeffm'; 'tbr' 

Subject: hermes 


Jay 

I've been running a test called hermes_store_unique 

(see /n/nosferatu/s2/euterpe/verify/toplevel) which is identical to the 

dram_store_unique test except for the fact that it accesses hermes. 


Here is what comes out of euterpe 


2533: Target: 0 ID: 0 
2580: Target: 0 ID: 0 
2673: Target: 0 ID: 0 
2720: Target: 0 ID: 0 
2813: Target: 0 ID: 0 
2825: Target: 0 ID: 1 
2860: Target: 0 ID: 0 

and this is what goes in 


Write Addr: 00000004 
Read Addr: 00000004 
Write Addr: 00000005 
Read Addr: 00000005 
Write Addr: 00000010 
Write Addr: 00000011 
Read Addr: 00000010 


Data: 0fle2d3c4b5a6978 

Data: 78695a4b3c2dle0f 

Data: 0123456789abcdef 
Data: 0fle2d3c4b5a6978 


1 1 8: Target: 0 ID: 0 WriteResponse 

161: Target: 0 ID: 0 ReadResponse Data: Ofl e2d3c4b5a6978 

258: Target: 0 ID: 0 WriteResponse 

301: Target: 0 ID: 0 ReadResponse Data: 78695a4b3c2dle0f 

398: Target: 0 ID: 0 WriteResponse 
410: Target: 0 ID: 1 WriteResponse 

441 : Target: 0 ID: 0 ReadResponse Data: 0123456789abcdef 

At this point the test hangs. 

Note that the test does not use interleaved space but just hermes channel 0 
module 0 at address 0, but a write to module 1 seems to be being issued by 
euterpe. 


The likedriverlog trace (actually hermesdebug.srl in toplevel) is on 

nosferatu /s2/euterpe/veri log/bsrc/res/ 1 9295 . 2 5 724/results/heimes_store_unique_0. dpo 


Lisa R. 
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From: woody (Jay Tomlinson) 

Sent: Monday, February 20, 1995 1:37 AM 

To: 'lisar (Lisa Robinson)' 

Cc: 'brian'; 'jeffm'; 'tbr' 

Subject: hermes 


Lisa Robinson wrote (on Sun Feb 19): 


Jay 

I've been running a test called hermes_store_unique 

(see /n/nosferatu/s2/euterpe/verify/toplevel) which is identical to the 

dram_store_unique test except for the fact that it accesses hermes. 


Here is what comes out of euterpe 


2533: Target: 0 ID: 0 
2580: Target: 0 ID: 0 
2673: Target: 0 ID: 0 
2720: Target: 0 ID: 0 
2813: Target: 0 ID: 0 
2825: Target: 0 ID: 1 
2860: Target: 0 ID: 0 

and this is what goes in 


Write Addr: 00000004 
Read Addr: 00000004 
Write Addr: 00000005 
Read Addr: 00000005 
Write Addr: 00000010 
Write Addr: 00000011 
Read Addr: 00000010 


Data: 0fle2d3c4b5a6978 

Data:78695a4b3c2dle0f 

Data: 0123456789abcdef 
Data: 0fle2d3c4b5a6978 


118: Target: 0 ID: 0 WriteResponse 

161: Target: 0 ID: 0 ReadResponse Data: 0fle2d3c4b5a6978 

258: Target: 0 ID: 0 WriteResponse 

301: Target: 0 ID: 0 ReadResponse Data: 78695a4b3c2dte0f 

398: Target: 0 ID: 0 WriteResponse 
410: Target: 0 ID: 1 WriteResponse 

44 1 : Target: 0 ID: 0 ReadResponse Data: 0 1 23456789abcdef 

At this point the test hangs. 

Note that the test does not use interleaved space but just hermes channel 0 
module 0 at address 0 5 but a write to module 1 seems to be being issued by 
euterpe. 


The likedriverlog trace (actually hermes_debug.srl in top level) is on 

n osferatu /s2/euterpe/veri log/bsrc/res/ 1 9295 .25724/resu lts/herm es_store_un i que_0 .dpo 


Lisa R. 


The test probably hangs becuase there is a outstanding request to the same 
address. In this case I can see a write to 0000001 1 which is probably followed 
by a read to the same address. If the write response is never received, or it 
is received and never gets sent (prb grant) to nb then it will hang. From 
looking at the .1st, I can't imagine why the request would go to ID 1 . It must 
have thought that it was in interleaved space. 


jay 


Exhibit Cll 


Page 388 of 559 


From: lisar (Lisa Robinson) 

Sent: Monday, February 20, 1995 8:24 AM 

To: 'woody' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr' 
Subject: BOM 233 


Jay 

The first run just finished and the only tests to fail were brmisseasy 
and brmisstest. The traces are on rhodan in 
/s3/euterpe/verilog/bsrc/res/20295. 1 86 1 5/results 
I'll run brmisseasy in verilog. 

Summary file is res/20295.1 8615/summary 


Design Name: i_euterpe_wrap 
Run Date: 20295 
Run ID: 18615 


Simulator: i_euterpe_wrap.ioj was built on Mon Feb 20 0:03:57 1995 
Using BOM: Version BOM,v 233.0 1995/02/19 22:45:43 LT woody 
Warning: Local BOM is out of date ... 
Log Message: 

Simulator: i_euterpe_wrap.ioj was built on Mon Feb 20 0:03:57 1995 
Using BOM: Version BOM,v 233.0 1995/02/19 22:45:43 LT woody 
Warning: Local BOM is out of date ... 
Log Message: 
Run finished at: 

Mon Feb 20 06:10:02 PST 1995 

Run started on host: rhodan at: Mon Feb 20 00:07:51 PST 1995 


testl0_0 Ran ok 
Run time = 140 seconds Performance = 

loadj) Ran ok 
Run time = 144 seconds Performance = 

storeuniqueO Ran ok 
Run time = 149 seconds Performance = 

memtest 0 Ran ok 
Run time = 202 seconds Performance s 

ibuf_storeeasy_0 Ran ok 
Run time = 1 52 seconds Performance = 

itag_storeeasy_0 Ran ok 
Run time = 152 seconds Performance = 

dtag_storeeasy_0 Ran ok 
Run time = 153 seconds Performance = 

Itlb^O Ran ok 
Run time ~ 147 seconds Performance = 

gtlb_0 Ran ok 
Run time - 152 seconds Performance = 
gtlbaccess4_0 Ran ok 


202 cycles/second 

196 cycles/second 

195 cycles/second 
247 cycles/second 

197 cycles/second 
197 cycles/second 

196 cycles/second 
204 cycles/second 
208 cycles/second 
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Run time = 315 seconds Performance = 264 cycles/second 

gtlbmisseasyj) Ran ok 
Run time = 301 seconds Performance = 260 cycles/second 

dcacheeasy_0 Ran ok 
Run time = 1494 seconds Performance = 301 cycles/second 

dcacheharderO Ran ok 
Run time = 1550 seconds Performance = 290 cycles/second 

dcacheannoying_0 Ran ok 
Run time = 1453 seconds Performance = 309 cycles/second 

dcachenoalloc_0 Ran ok 
Run time = 1 505 seconds Performance = 299 cycles/second 

brmisseasy 0 (in fail loop) Failed 
Run time = 217 seconds Performance = 230 cycles/second 

brmisstest_0 (in fail loop) Failed 
Run time = 295 seconds Performance = 282 cycles/second 

icacheharder_0 Ran ok 
Run time = 23 1 seconds Performance = 230 cycles/second 

icachemissj) Ran ok 
Run time = 425 seconds Performance = 274 cycles/second 

icacheannoying_0 Ran ok 
Run time = 296 seconds Performance = 28 1 cycles/second 

nbuseeasy_0 Ran ok 
Run time = 244 seconds Performance = 239 cycles/second 

nbfulltestj) Ran ok 
Run time = 183 seconds Performance = 218 cycles/second 

nbhiprio_0 Ran ok 
Run time = 321 seconds Performance = 259 cycles/second 

dram_load_0 Ran ok 
Run time = 196 seconds Performance = 255 cycles/second 

dram_store_unique_0 Ran ok 
Run time = 210 seconds Performance = 238 cycles/second 

bdownharder 0 Ran ok 
Run time =161 seconds Performance = 207 cycles/second 

sysprotol_l Ran ok 
Run time = 193 seconds Performance = 259 cycles/second 

sysproto2_l Ran ok 
Run time = 912 seconds Performance = 365 cycles/second 

cerbeasy_0 Ran ok 
Run time = 248 seconds Performance = 235 cycles/second 
Total number cycles run = 3392500 


Lisa R. 
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From: wampler (Kurt Wampler) 

Sent: Monday, February 20, 1995 8:00 PM 

To: 'tbr' 

Subject: Re: GARS long names 

> What's the status of the long name support in GARBS? 

> 

>I see the satndard flow is still using the mangled names. 

Longname support is advertised as being "fully implemented" in this version 
of GARDS. To enable it, you set the "systemnames" parameter to "true" 
for tools like GPLACE, REDIT, etc. When this change is made, all files 
of netnames, component names, PIF/POF files, etc. must all use longnames 
instead of shortnames. 

What we should perhaps do to ease into longname mode is to start compiling 
our dff files with the longnames available (we can still switch back and 
forth between longname and shortname mode on a per-tool basis), and that 
way we can begin to make longnames available for interactive GPLACE and 
REDIT sessions. 

I am getting longnames compiled in to gardswarts now, but for some reason 
that I don't yet fully understand the top-level Euterpe dff s I'm getting 
from Geert don't have any longnames in them. It may be an SDL vs. EDIF 
thing. I'll investigate further. 

-Kurt 

(One other thing I've noticed; GPLACE & REDIT support left-right scrolling 
of the names window [where a name is too wide to display it fully in the 
window] for component names, but not for netnames. This looks like a bug. 
It's a nuisance, though, and ought to be fixed.) 
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From: 
Sent: 
To: 

Subject: 


Scott Furman [fur@quetzalcoatl] 
Monday, February 20, 1995 8:11 PM 
'abbott (Curtis Abbott)' 
hacking on huffman 


Curtis Abbott writes: 

> I was looking at the place where you do DECODE_DCT_COEFF_FAST { ) 6 > times in 
parse_dct_coef f s . Counting cycles by hand, it looks like it > should take 20 
cycles/call, though 22 for the first one. I hacked it > up and believe I got it to 12 
cycles, which is a significant savings. 

> However, there are a few problems. 


> 1. some of the hacks I did may be hard to get the compiler to do, > and/or express in 
C. for example, I moved the store past the > underflow branch. 

For a *long* time, the compiler has scheduled this loop as 14 cycles for the first 
iteration and 16 cycles for each subsequent iteration. 

I was surprised to see your note about this matter so I tried compiling this loop again 
and was disturbed at the outcome. What you have discovered is a recent regression in 
compiler optimization. 

Here's excerpt code from that loop as the compiler schedules it now: 


Obviously, the compiler has lost it's mind, as these two instructions should be combined 
into a single one. . I don't know how long the compiler has been doing this; The benchmark 
performance reports since November continue to show an overall improving trend, with small 
fluctuations. With the two instances of this compiler code generation problem fixed, the 
schedule for each iteration should revert back to 


Anyway, you can do better than 16 cycles for the selected instructions using an irregular 
schedule, but the compiler does not currently discover it because it requires speculative 
execution, e.g. moving the store past the branch. The irregular schedule can perform two 
iterations in 28 cycles instead of the 32 cycles that the best-case regular schedule 
requires. The compiler is not likely to generate this schedule of its own accord for some 
time, as speculative execution is a fairly advanced optimization. You can ask Ray for his 
notes on this improved schedule, if you like. Also, FYI , I reproduce at the end of this 
mail the note I sent to Ray Hayes in mid-November concerning the scheduling of this code. 
{This is one of the loops that Ray regularly uses to test his scheduler ideas.) 

As far as improving this schedule goes, it's going to be hard to break the current 
sixteen- cycle barrier with a *regular* schedule. The "rounding" effect of the issue 
restrictions imposed by the store requires that two cycles be shaved to reduce the 
schedule to twelve cycles. (Getting rid of only one cycle doesn't help at all as it 
simply gets added back as a store issue restriction) . Obviously, you can change the 
underflow checking to be less frequent, thus removing a nasty branch from the middle of 
these two basic blocks, but that does not change the bottom line for the scheduling of 
each iteration and it has some unpleasant performance aspects for other parts of the code. 
(It increases bit stream underflow frequency -- Yes, it's been tried.) 

> 2. there's a *lot* of code generated around this. even a large > speedup in the 
"inner loop" will get severely diluted by all the > overhead code, it ' s a big 
complicated thing, and hard to imagine > effectively working on at assembler level. 

Actually, the common path through the outer bitstream underflow loop represents a fairly 
small portion of the code. In any case, the outer loop (the bitstream underflow loop) 
*is* where we've been spending our time recently. The current ideas for improvement hinge 
around "unique" pointer declarations to allow the compiler to better disambiguate memory 
references. This should especially allow improvements near bitstream code. 

> 3 . I removed several instructions by being cleverer than the compiler > about knowing 


eadd 
lu321i 


r30, r53, r29 
r8 , r30, 0 


16 cycles. 
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I only cared about 12 bits for the load offset register. 


Just wondering: Has this code been tested ? Looking at it, I can't see how it could have 
worked. There appears to be at least one bug (using an unsigned withdraw instead of a 
signed one for the level) and one missing instruction (potentially leaving dangerous bits 
set in the load offset register; I also think there may be some confusion about this idea 
of caring only , "about 12 bits for the load offset 

register.") If you fix these problems, you're back to the identical performance level as 
the existing code. I'm probably just being clueless, though. I'll let you explain it to 
me on Tuesday. 

> Clearly, if we could get the whole front end of the mpeg decoder to > 60% of its 
current cycle count, it would be a big deal. I'd like to > have a session with you next 
week on the mechanical procedures you use > to test different options for performance 
(and correctness) . 

> Meanwhile, the code I did can be found in parse_mb_hacked . s ; I also > made changes to 
VLC_ENTRY() and GET_LEVEL ( ) in huffman.h. (No, I > won't be checking these in.) > 

It's not likely we'll ever see a 60% improvement, at least not for worst -case input data. 
When I did my testing in October, the decoder spent 25% of its parsing time just in this 
16-cycle inner loop and 35% of its parsing time in parse_dct_coef f s ( ) when handling 
♦worst- case* input. (Intuitively, that makes sense: 5 million coefficients per second 
times 16 cycles per coefficient is 80 million cycles/second in the inner loop. It was 
taking a total of about 350 million major cycles per second [sic] to parse worst-case data 
including macroblock headers, slice headers, etc.) We could get a 65% improvement for 
worst-case input, for example, by achieving * infinite* speedup in all of the parsing 
routines outside of parse_dct_coef f s ( ) . Obviously, this is not likely to happen. Also, 
given these figures, improving 

parse_dct_coef f s ( ) so that it is infinitely fast would not achieve the 60% speedup either. 
I think a 25% performance speedup for worst-case data is more realistic. 

If we want improved performance on the video decoder " f ront - end " , I think we should 
concentrate in two main areas: First, we need many general improvements to scalar code 
generation for the compiler, particularly in the area of scheduling and memory 
disambiguation. I am not talking about particularly advanced optimizations, just the sort 
that any decent compiler should do (and which tec does not). If we can't get sufficient 
improvements from these tactics, we should consider major surgery on the video decoder. 
For example, per-slice decoding has been suggested many times in the last couple of years. 
It may be time to take the idea more seriously though, as you know, the advantages in 
terms of parallelization may very well be outweighed by increased SDRAM bandwidth 
requirements and additional consumption of on-chip memory. 


Message send to Ray Hayes on 11/16/94: 

This is the heart of the DCT coefficient Huffman decoder. For 
worst -case input, the 12 -instruction loop below should account for 
nearly half of the cycles spent parsing MPEG input data. (The 
remaining cycles are expended in a much larger body of code that 
compiles to several thousand instructions. Less effort has been spent 
on optimizing these other types of MPEG data parsing routines because 
they are less "dense".) 

It should be pointed out that the chosen Huff man- decoding algorithm 
was designed with our current microarchitecture in mind. With a 
different set of constraints, this Huffman decoder might have been 
designed very differently. For example, if branch misprediction 
penalties and memory-op issue restrictions were less severe, it might 
be cheaper to compute a branch address based on the first few leading 
bits of the bitstream. In this case, there would be a separate code 
sequence for each possible combination of leading bits, allowing 
multiple codewords to be decoded at the same time. 

The loop below performs a direct "fast" table lookup based on the 
leading nine bits of the variable- length code (VLC) . If the VLC is 
short enough that these few bits completely specify the codeword, the 
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DCT coefficients are reconstructed from data in the table entry. 
Otherwise, the fast decoding is aborted and control is transferred to 
an "exception" dispatcher that completes the decoding. 

An "exception" occurs when: 

A) We've run off the end of our 8x8 matrix, which indicates the 
presence of illegal input data, or 

B) The VLC was not a "short" codeword. It must be one of these: 

1) end-of-block code 

2) escape- code (followed by escaped run and level data) 

3) "long" codeword {greater than nine bits long) 

By clever encoding of the lookup table entry, we can test for all 
these conditions with a single branch. Each Huffman decoding table 
entry is a triple { LENGTH , LEVEL, Rim} indicating the length of the 
Huffman codeword, the value of the non-zero coefficient and the number 
of preceding zero coefficients, respectively. Actually, the value 
(RUN +1) is stored in the table rather than RUN, and sometimes the 
table contains an exception code in place of the RUN value. This is 
the layout of a table entry in memory: 


8 

16 

8 

Codeword | 
| Length j 

LEVEL 

| (RUN +1) or | 
| exception code [ 


In the loop surrounding the innermost loop (not shown) , data is parsed 
from the input bit stream in chunks of almost 12 8 bits (actually 117 
bits) . The branch at the end of the loop detects when the single 
hexlet of input data is exhausted. If so, it is refilled from the 
memory-mapped input queue and the loop is restarted. With 
minimum- length coefficients, which are 3 bits long, this buffer hexlet 
should only need to be refilled roughly every 3 0 iterations of the 
inner loop. 

The first iteration of the 12- instruction loop can be scheduled in 14 
cycles. However, due to issue restrictions on store instructions, 
subsequent iterations must begin on a multiple of 4 cycles, so each 
iteration requires 16 cycles, for an IPC of 0.75. 


; Cycle Description 


gushrl2 8 

r2, r6, r36 


; 0 

Get leading bits of 

bitstream 







1 

STALL: 

+1 (Regdep) 

eandi 

r2,r2, 2044 


; 2 

Get leading 6 bits 

of bitstream 





lu3 21 

r2, r51, r2 


; 3 

Lookup Huffman 

table entry 




+1 (Regdep) 



4 

STALL: 

eadd 

r3 , r5 9, r2 


; 5 

Compute new zigzag 

index 





eushri 

r8,r2, 8 


; 6 

Get (RUN + 1) (# of 

zeros plus one) 





bandne 

r3, r4 8, . LG03E 

55 

; 7 

Do we have an 

exception ? 





eandi 

r59, r3, 63 


; 8 

Mask off unused 

bits of index 





lu8 

r3, r53,r59 


; 9 

Convert zig-zag to 

linear index 





eushri 

r4,r2,24 


; 10 

Get codeword length 
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S161 r8,r57,r3 ; 11 Store in 

destination matrix 

esub r36,r3 6,r4 ; 12 Compute new 

bitstream cursor 

biz r36, .LGQ41.55 ; 13 Bitstream underflow 


-Scott 
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From: wampler (Kurt Wampler) 

Sent: Tuesday, February 21, 1995 12:53 AM 

To: 'tbr' 

Subject: Re: GARS long names 

The reason longnames aren't getting stored in the dff for the top-level 
Euterpe seems to be because no top structure is selected when we run 
SLNET. However, when I select a top structure, SLNET performance degraded 
by at least an order of magnitude. Not sure what it's doing, but it ain't 
behaving properly. I'm going to have to talk to someone at SVR about this 
tomorrow (Tuesday). I'll let you know what I find out. 

-Kurt 
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From: jeffm (Jeff Marr) 

Sent: Tuesday, February 21 , 1 995 1 :54 AM 

To: 'lisar (Lisa Robinson)' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'for 1 ; 'woody' 

Subject: BOM 233 

Lisa Robinson writes: 

> 

> Jay 

> 

> The first run just finished and the only tests to fail were brmisseasy 

> and brmisstest. The traces are on rhodan in 

> /s3/euterpe/verilog/bsrc/res/20295 .1861 5/results 

> I'll run brmisseasy in verilog. 

Just scanned the brmisseasy .dpo file to see what was what. 

The test gets an unexpected rsvd inst exception when branching to 
20000004000. The instruction that should have been executed is a 
branch. This address uses the same i cache slot as the beginning of 
the predicted branch loop from which the register branch to the 
alias occured. The icache fill did happen before the rsvd inst was 
executed - but the cache fill was all zeros, thus the rsvd inst. 

jeffm 
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From: iisar (Lisa Robinson) 

Sent: Tuesday, February 21, 1995 2:05 AM 

To: 'jeffm' 

Cc: 'billz'; 'dickson'; 'mws'; 'tor'; 'woody' 
Subject: Re: BOM 233 

I just can't seem to reproduce this in verilog. I have run it 4 times 
out of a possible 5 and each time it fabbed. I just picked up 
mws's BOM and I'm going to run that as soon as it has built. 

m go back to looking at brmisseasy then! 


> The first run just finished and the only tests to fail were brmisseasy 

> and brmisstest. The traces are on rhodan in 

> /s3/euterpe/verilog/bsrc/res/20295. 1 86 1 5/results 

> I'll run brmisseasy in verilog. 

Just scanned the brmisseasy ,dpo file to see what was what. 

The test gets an unexpected rsvd inst exception when branching to 
20000004000. The instruction that should have been executed is a 
branch. This address uses the same icache slot as the beginning of 
the predicted branch loop from which the register branch to the 
alias occured. The icache fill did happen before the rsvd inst was 
executed - but the cache fill was all zeros, thus the rsvd inst. 

jeffm 


Exhibit Cll 


Page 398 of 559 


Sent: 
To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Tuesday, February 21, 1995 2:54 AM 

Tom Laidig (tau)' 

Vanthof@MicroUnjty.com'; 'cadettes'; 'geert (Geert Rosseel)'; Vo (Tom Vo)'; 'wingard (Drew 


Subject: 


Wingard)'; 'tau' 
Re: CSM dbu's? 


Tom Laidig (tau) writes: 

Ah, yes, integer vs not... 

[Tom's cogent summary er... shortened] 

I could support, I think, both sides in this argument. In the end, however, I come down 
on the side of integer. While I too view the difference as somewhat philosophical, I think 
that use of integers is less error- prone _overall_. I have this nagging thought that just 
as we're about to tapeout we find some niggling little tool (perhaps one we did not even 
write) which uses %6.0f format and drops a significant bit. 

Let's talk with the mask designers, too. 


-hopper 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, February 21, 1995 9:50 AM 

To: 'cadettes*; 'geert (Geert Rosseei)' 

Cc: 'tbr (Tim B. Robinson)' 

Subject: CSM rules 


Hi, 

I've spoken with most of the CAD folk now, with Geert and Drew and 
Mike and Orlando. The consensus seems to be that it would be okay 
at worst and a good thing at best if we switch to integer design rules. 

I will send out imminent decision mail shortly 

-thanks, 
hopper 
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Sent: 

To: 

Cc: 


Subject: 


From: 


torn (Tom Laidig (tau)) 

Tuesday, February 21, 1995 9:57 AM 

Vant' 

'cadettes'; 'geert (Geert Rosseel)'; Vo (Tom Vo)\ 'wingard (Drew Wingard)'; 'tau' 
Re: CSM dbu's? 


Ah, yes, integer vs not... 

I guess my own feeling is that, when all coordinates are required to be a multiple of some 
grid, it's cleaner to express them as an integer multiple of the stepping unit. I thought 
that was the right choice with the roller technology; I thought it was the right choice 
with the mobimos technology; and it's the choice I would have made for csm as well. For 
me, though, this is primarily a philosophical issue, so I didn't argue much when Dave was 
setting up the layout and drc infrastructure. 

As far as what's easier and what's harder, it seems the main difference is where the 
burden lies. There are numerous tools (vlsimm, close to my heart, is one) that internally 
use integer coordinates to speed computation, reduce memory consumption, and assure a 
reliable accuracy. 

If the database stepping unit is not an integer, a scale factor must be specified each 
time any such tool is used. This can be buried in Makefiles and drc flows for many cases, 
but it reappears in all the one-off tool uses. On the flip side, using integer 
coordinates means converting between microns and dbus whenever someone has originally 
expressed a dimension in microns. I don't actually think either is especially error- 
prone: if anything, it seems to me that going to an integer grid is less error-prone, 
since you'd have a hard time drawing fractional dimensions in compass if its snap grid 
were set to 1, whereas you might reasonably run some batch tool and not notice that 
coordinates had been snapped to a coarser grid in the process. 

To some of the specific points: 

vant writes: 

>Kurt Wampler writes: 
> 

> - The abgen program uses a bitmap -based compactor to consolidate 
obstruction 

|> data for GARDS . The X- and Y-coordinates of geometry are used to 
index 

| > bitmap arrays . The algorithm only works with integer X- and 
Y-coordinates . 

Multiply the incoming data by 10 for the CSM technology. 


> - We have a number of vlsimm scripts embedded in 
Makefiles/shell- scripts 

| > which may produce erroneous results due to round-off errors; each one 
j > will have to be modified to magnify the incoming data sufficiently to 
)> integerize it, 

jl've set up the drc environment to automatically change the 'inscale 1 
value 

1 based on the technology. This should be doable for baseplate 

j generation 

as 


The difference, I think, is that the drc environment is pretty monolithic, so it's easy to 
put in a global scaling factor there, while the baseplate generation (a fairly nebulous 
term, I think) consists of a lot of bits and pieces scattered in lots of places. 


| well. 


I> 
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> - The baseplate generation code uses the M4 preprocessor, which can't 

> handle floating point numbers. 

I'm really confused. I thought Geert already has some baseplate built. 

Geert has built a baseplate layout. He wrote the coordinates in dbus, as I understand it, 
thus doing the multiplication by 10 that drawing in microns was supposed to avoid. 

[hopper askes if changing is feasible] 

It's doable. Every layout will need to be scaled. the drc flow will 
need to have every number changed (monotonous , but easy) . It's best to 
do 

this in a coordinated fashion so as to confuse layout folks as little 
as possible. Then retraining of the layout folks is needed. Has 
anyone 
bo t herd 

| to consult with any layout people? They are intimately involved here 
| as 
well 

| and should be involved in the final decision. 
Changes we'd need to make: 
change drc flow 

scale all layouts (simple vlsimm run on each) 

change snapping value (s?) in common vlsi.boo file 

change value of "lvsscale' in spice models file 

change stuff geert did to the baseplate layout generation 

teach people to do things the way they've been doing them for the 
last couple years 

i 

| The fact the a .1 micron resolution is being used for CSM has not been 
j a secret so I'm confused about what has happened to bring up these 
concerns . 

Well, although it's been no secret, it was never announced very loudly either. I think 
the concerns are being brought up as different people get a break from euterpe and start 
looking at cronus . When Geert started working on the baseplate a week or two ago, he 
noticed the non- integer coordinates with respect to baseplate layout generation, and 
griped a bit. He then found a workaround, and proceeded. Kurt has now had some time to 
look at cronus, and so he's noticing. I would expect this process to continue for a bit 
longer, as I think it has any time we've changed methodology. 

| Changing a few tools to be more flexible seems to be a better answer. 

Well, there are really two bits here: changing the tools to permit non- integer 
coordinates, and changing all the uses of these tools to make use of that permission. The 
first is not a bad thing; the second is the more questionable one in my view. 


Bottom line for me: As I said, I think integer coordinates are cleaner, neater, and more 
inherently exact. I also find them easier to deal with, personally. So I'd have 
continued to use them in atlas if I'd made the choice. OTOH, I don't know that it's that 
big a deal. So while I'd support changing back to integer coordinates, I'd also go along 
with the fractions without complaint. 
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Sent: 
To: 

Subject: 


From: 


tbr 

Tuesday, February 21, 1995 10:45 AM 
'wampler (Kurt Wampler)' 
Re: GARS long names 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Mon Feb 20): 

The reason longnames aren't getting stored in the dff for the top-level 
Euterpe seems to be because no top structure is selected when we run 
SLNET. However, when I select a top structure, SLNET performance degraded 
by at least an order of magnitude. Not sure what it's doing, but it ain't 
behaving properly. I'm going to have to talk to someone at SVR about this 
tomorrow (Tuesday). I'll let you know what I find out. 

OK, thanks. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Tuesday, February 21, 1995 11:25 AM 
'Bang Q. Vu' 
Re: Device Driver 


Hi Bang 


I did some device driver work before at NeXT, but details of installing device drivers 
vary from vender to vendor. Most now have some facility for dynamically installing device 
drivers into a running system. Previously, one would have to make some modifications to 
some driver specification files and re-link to get the new device driver added. 


Gregg Kellogg 

MicroUnity Systems Engineering, inc. 

255 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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From: woody (Jay Tomlinson) 

Sent: Tuesday, February 21 , 1995 12:50 PM 

To: 'fwo (Fred Obermeier)' 

Cc: 'fwo'; 'hardheads' 

Subject: Csyn Euterpe BOM 229 errors 


Fred Obermeier wrote (on Fri Feb 17) : 

error (OutputShortCheck. 1417) in file " tbr_euterpe-passl . spivs" : 
net has too many drivers 


topmost net: 


instance 

path: 

cellname 

path: 

drivers : 


instance 

path: 

cellname 

path: 

instance 

path: 

cellname 

path: 

topmost net: 


instance 

path: 

cellname 

path: 

drivers : 


instance 

path: 

cellname 

path: 

instance 

path: 

cellname 

path: 


top . atcimissvldrl2 
top . atcimissvldrl2 

top . xatucimssvldccrl2u0 . atcimissvldrl2 
top.xborf f 5df 8s .CLandOpf 
top . xatucimssvld2crl2u0 . atcimissvldrl2 
top.xborf f5df 8 s .q__and0pf 


top . atcimissvldrl2_n 
top . atcimissvldrl2_n 

top . xatucimssvldccrl2u0 . atcimissvldrl2_n 
top, xborf f 5df 8s . q_ad0pf 

top.xatucimssvld2crl2u0 . atcimissvldrl2_n 
top.xborf f5df 8s . q_ad0pf 

error (OutputShortCheck. 1465) in file " tbr_euterpe- pas si . spivs" : 
w/y drivers must have same swing 

fixed checked in. 


Day 
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From: ken (Ken Hsieh) 

Sent: Tuesday, February 21 , 1995 12:55 PM 

To: 'woody' 

Cc: 'sysadm' 

Subject: Re: Csyn Euterpe BOM 229 errors 


The SGI technical engineer told me that as long as it did not crash 
you system you can ignor them. 

Ken 

> From woody Tue Feb 2 1 1 0:50: 1 5 1 995 

> Date: Tue, 21 Feb 1995 10:50:07 -0800 

> From: woody (Jay Tomlinson) 

> To: fwo (Fred Obermeier) 

> Cc: fwo, hardheads 

> Subject: Csyn Euterpe BOM 229 errors 

> Content-Length: 1036 
> 

> 

> Fred Obermeier wrote (on Fri Feb 17): 

> error (OutputShortCheck. 14 1 7) in file "tbr euterpe-pass 1 .spivs" : 

> net has too many drivers 

> 

> topmost net: 

> instance path: top.atcimissvidrl2 

> eel In am e path: top.atcimissvldrl2 

> drivers: 

> instance path: top.xatucimssvldccrl2u0.atcimissvldrl2 

> cellname path: top.xborfBdfiBs ,q_and0pf 

> instance path: top.xamcimssvld2crl2u0.atcimissvldrl2 

> cellname path: top.xborfT5df8s ,q_and0pf 

> 

> topmost net: 

> instance path: top.atcimissvldrl2_n 

> cellname path: top. atcimissvldrl2_n 

> drivers: 

> instance path: top.xatucimssvldccrl2u0.atcimissvldrl2_n 

> cellname path: top.xborfT5df8s .q_ad0pf 

> instance path: top.xatucimssvld2crl2u0.atcimissvldrl2_n 

> cellname path: top.xborff5df8s .q_ad0pf 

> 

> error (OutputShortCheck. 1 465) in file "tbr_euterpe-pass 1 .spivs" : 

> w/y drivers must have same swing 

> 

> fixed checked in. 

> 

>jay 
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From: wampler (Kurt Wampler) 

Sent: Tuesday, February 21 , 1 995 1 :02 PM 

To: 'tbr' 

Cc: 'geert'; 'hopper'; 'torn' 

Subject: Re: netcap file for maze result 


©Kurt Wampler wrote (on Sat Feb 18) ; 

@ 

@ Perhaps one way to collate this analysis would be to examine the 

ratio 

@ between actual capacitance and estimated capacitance, discard any 

where 

@ the ratio is 1.0 or less, and sort in descending order by ratio? 

© 

©That would be great. Also just for interest, can we get the ©overal percentage of how 
many are are greater then 1.0. If the number ©is big, we may want to adjust the fudge 
factor we use in the initial ©estimates. 

Well, I've done a little crunching. In the file: 

/n/godzilla/s2/wampler/euroute/geert_euterpe-iter .cwl 

There is a comparative list of actual wire length versus estimated wire 
length, sorted in descending order of percentage overestimate. Don't 
panic immediately; some of the > 100 0% errors are really short nets that 
were routed by the M2maze step. 

There are, however, some examples of pretty bad routing revealed by this 
list. 

Other interesting factoids: 

- About 48% of the nets routed within their estimated wire length. 

- Around 1% of the nets routed in *less* than their estimated wire length, 

- Around 1% of the nets routed in 2X or more of their estimated wire length. 

Another file of interest is: 

/n/godzil la/ s2 /wampler /euroute/m2high. cap 

This is just a GARDS .cap file sorted in descending order of M2 wirelength. 
Many of the nets showing lmm+ of M2 length appear to be due to missing 
DELAY+14 obstruction over the clock mast. I thought I had this fixed 
(I inserted some clockbias code back in December to address this 
problem) 

but it looks like I didn't complete my work and although the mast obstruction 
is being computed, it's never being added to cgclockbias .pdl . I'll fix this 
today if I can. 

- Kurt 
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From: Gregg Kellogg [gregg@hts.microunity.com] 

Sent: Tuesday, February 21 , 1 995 1 :07 PM 

To: 'Bang Q. Vu'; 'Gregg Kellogg' 

Subject: Re: Device Driver 


On Feb 21, 1:03pm, Bang Q. Vu wrote: 

> Subject: Re: Device Driver 

> Gregg Kellogg penned: 

> : 

> : Hi Bang. 

> : 

> : I did some device driver work before at NeXT, but details of 
installing 

device 

> : drivers vary from vender to vendor. Most now have some facility for 

> : dynamically installing device drivers into a running system. 
Previously, 

one 

> : would have to make some modifications to some driver specification 
files 

and 

> : re -link to get the new device driver added. 


;> : — 

> : Gregg Kellogg 

> : MicroUnity Systems Engineering, Inc. 

> : 255 Caspian Drive, Sunnyvale, Ca 94089-1015 

> : gregg@mi crounity.com 


> Hi Gregg, i'm looking for ways to write a dev. driver for SGI IRIX 5.2. 
Just 

try to 

> pick your brain in case you've already done similar work. Thanks. 
> 

> Bang Vu 

> Western Geophysical, Western Atlas Intl., Inc. 

> Email : vu@wg2.waii.com 

> Voice : (713) 964-6192 

> Fax : (713) 964-6218 

>-- End of excerpt from Bang Q. Vu 

Sorry I can 1 1 help you out any more . 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc . 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: torn (Tom Laidig (tau)) 

Sent: Tuesday, February 21, 1995 1:31 PM 

To: 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)' 

Cc: 'tau' 

Subject: Creole tape 

OK, the first error I encountered is when running 

gmake -C proteus/verilog/libsrc everything 

I get to where it's building some ikos thing, and it doesn't have 
proteus/ikos/projectxfg, because I haven't included proteus/ikos in the 
stuff I'm checking out. Is it OK to send proteus/ikos to the Creoles? 
All of it, or part? 

Also, last quarter we didn't send anything from mnemo, since it was just 
starting to exist. I guess we should change that for this tape. For 
reference, here's what we now do for the euterpe tree: 

include euterpe 

exclude euterpe/verilog/bsrc/dr/dram/mit 

run In -s ../proteus euterpe 

run In -s /u/chip/tools euterpe 

run rm -rf euterpe/clockbias; mkdir euterpe/clockbias 

run cp /u/chip/euterpe/clockbias/*.edif euterpe/clockbias 

run gmake -C euterpe/verilog/bsrc vfiles 
exclude euterpe/compass 

(where 'include' translates to a 'cvs co' } 'exclude' to 'rm -r', and 
'run* does a shell command) 

Is mnemo sufficiently similar that the following would be about right? 

include mnemo 

run In -s ../proteus mnemo 

run In -s /u/chip/tools mnemo 

run rm -rf mnemo/clockbias; mkdir mnemo/clockbias 

run cp /u/chip/mnemo/clockbias/*.edif mnemo/clockbias 

run gmake -C mnemo/verilog/src vfiles 
exclude mnemo/compass 
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From: tbr 

Sent: Tuesday, February 21 , 1 995 1 :46 PM 

To: 'ken (Ken Hsieh)' 

Cc: 'sysadm'; 'gmo'; 'woody' 

Subject: Re: Csyn Euterpe BOM 229 errors 

Follow Up Flag: Follow up 

Flag Status: Red 


Interesting crossing of wires here (in more than one sense)! 
The csyn problem is an error in our Euterpe design database, not 
something we should be discussing with SGI I I assume this was meant 
to go to gmo. 

However, on that score, the issue is whether the problem is transient 
(ie a soft error), or reproducible/recurrent. If the latter, we 
should be swapping out the SIMM, and we do have spares in stock if 
that proves necessary. 

Tim 


Ken Hsieh wrote (on Tue Feb 2 1 ): 


The SGI technical engineer told me that as long as it did not crash 
you system you can ignor them. 

Ken 

> From woody Tue Feb 21 10:50: 15 1995 

> Date: Tue, 21 Feb 1995 10:50:07 -0800 

> From: woody (Jay Tomlinson) 

> To: two (Fred Obermeier) 

> Cc: two, hardheads 

> Subject: Csyn Euterpe BOM 229 errors 

> Content-Length: 1036 
> 

> 

> Fred Obermeier wrote (on Fri Feb 1 7): 

> error (OutputShortCheck. 1 4 1 7) in file "tbr euterpe-pass 1 .spivs" : 

> net has too many drivers 

> 

> topmost net: 

> instance path: top.atcimissvldrl2 

> cellname path: top.atcimissvldrl2 

> drivers: 

> instance path: top.xatucimssvldccr12u0.atcimissvldrl2 

> cellname path: top.xborff5df8s .q_and0pf 

> instance path: top.xatucimssvld2crl2u0.atcimissvldrl2 

> cellname path: top.xborff5df8s .qjmdOpf 

> 

> topmost net: 

> instance path: top.atcimissvldrl2_n 
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> cellname path: top.atcimissvldrl2_n 

> drivers: 

> instance path: top.xatucimssvldccrl2u0.atcimissvldrl2_n 

> cellname path: top.xborf¥5df8s .q_adOpf 

> instance path: top.xatucimssvld2crl2u0.atcimissvldrl2_n 

> cellname path: top.xborffSdfBs .q_adOpf 

> 

> error (OutputShortCheck. 1465) in file "tbr_euterpe-passl . spivs": 

> w/y drivers must have same swing 

> 

> fixed checked in. 

> 

>jay 
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From: 
Sent: 
To: 


sysadm on behalf of gmo (Guillermo A. Loyola) 
Tuesday, February 21, 1995 2:00 PM 
'pandora@news' 


I think we are mixing several different discussions here which don't necessaraly belong 
together. 

First question is how to connect a ROM to Cerberus, which in an implementation of 
Terpsichore without an onboard ROM interface is of paramount importance; in an MPP 
application is quite important so you can share the ROM; but for Euterpe in Hestia or 
Pandora is a lot less interesting. 

The more interesting question is How do we debug a Hestia- like box using Pandora? I would 
say that the minimum requirements are 1. To be able to reset Hestia *without* having to 
reset Pandora at the same time, and 2. To be able to read and write Cerberus registers in 
Hestia 's devices from Pandora. 
Although 

not a "minimum" requirement, we have been assuming that we will have (at least in the pre- 
Pandora cross-development environment) 3. A promiscous-master- slave interface that allows 
us to snoop on all Cerberus transactions and also to respond to any unused Cerberus 
address. 

A direct connection between Pandora's Cerberus bus and Hestia ' s Cerberus bus allows us to 
do #2 above, but not #1 and certanly not #3; so it is only mildly instersting. 

What Dave had talked about a couple of weeks ago sounded to me like a plan to implement an 
interface that would give us all 3 directly in Mnemo, which is fine by me, but only if it 
is easy to do with a minumal impact on Mnemo 1 s schedule; and it certanly does not require 
Mnemo to have a ROM interface. 

Now, given an ISA board implementing all 3 capabilities, and the fact that Pandora will 
have ISA slots, I don't think we need anything else. But we 
*do* need to get such a board designed and built! 

Quite aside from the question of using Pandora, I'd like a clarification on Tim's 
statement: " [ the Cerberus address ] in the Hestia to be non-zero (we have pin on the 
expansion connector to force that)". I thought that at least on the current Hestia PCB 
this was accomplished with a jumper inside the box, not with a pin accessable to the 
outside; Which is it? 


Gmo. 
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From: Guillermo A. Loyola [gmo@bilbo] 
Sent: Tuesday, February 21, 1995 2:03 PM 
To: Ken Hsieh'; 'tbr@bilbo' 
Cc: 'woody@bilbo'; 'sysadm@bilbo' 
Subject: Re: Csyn Euterpe BOM 229 errors 

The SGI technical engineer told me that as long as it did not crash 
you system you can ignor them. 

I don't think that "not crashing the system" as in a kernel crash is an acceptable 
measure of the importance of the error. I think any errors should be tracked. 
We probably shouldn't do anything else for recoverable errors, but when we have 
a non-recoverable error, we should pay attention. The fact that the error happened 
while a user process was running, killing that process instead of crashing the 
system is irrelevant. In fact the "gmake" that died because of bilbo's memory 
error earlier today was doing an "official" software build, so it certanly was 
important for us. 

I'm willing to wait to see if/when the error reoccurs before doing anything else, 
but we probably should press SGI or our memory vendor a little harder if it is 
still the case -as it used to be- that a significant number of the SGI machines 
get hard memory errors regularly (The old bilbo used to get them every 4-6 weeks). 

Gmo. 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Tuesday, February 21, 1995 3:46 PM 
'torn (Tom Laidig (tau)' 
'lisar (Lisa Robinson)'; 'tau' 
Creole tape 


Follow Up Flag: Follow up 
Flag Status: Red 

tau wrote (on Tue Feb 21): 

OK, the first error I encountered is when running 

gmake -C proteus/verilog/libsrc everything 

I get to where it's building some ikos thing, and it doesn't have 
proteus/ikos/project.cfg, because I haven't included proteus/ikos in the 
stuff I'm checking out. Is it OK to send proteus/ikos to the Creoles? 
All of it, or part? 

I think we should exclude this. There are files checked in there that 
come direct from IKOS and could well be considered proprietary. 

Also, last quarter we didn't send anything from mnemo, since it was just 
starting to exist. I guess we should change that for this tape. For 
reference, here's what we now do for the euterpe tree: 

include euterpe 

exclude euterpe/verilog/bsrc/dr/dram/mit 

run In -s ../proteus euterpe 

run In -s /u/chip/tools euterpe 

run rm -rf euterpe/clockbias; mkdir euterpe/clockbias 

run cp /u/chip/euterpe/clockbias/*.edif euterpe/clockbias 

run gmake -C euterpe/verilog/bsrc vfiles 

exclude euterpe/compass 

(where * include' translates to a *cvs co', 'exclude' to 'rm -r', and 
run' does a shell command) 

Is mnemo sufficiently similar that the following would be about right? 

include mnemo 

run In -s ../proteus mnemo 

run In -s /u/chip/tools mnemo 

run rm -rf mnemo/clockbias; mkdir mnemo/clockbias 

run cp /u/chip/mnemo/clockbias/*.edif mnemo/clockbias 

run gmake -C mnemo/verilog/src vfiles 

exclude mnemo/compass 

Mnemo should be exactly the same structure except that under verilog we 
have 'src' not 'bsrc' (which I see you have already accounted for). 

Remind me why we are excludeing the compass directory. . . 
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From: hchu (Herman Chu) 

Sent: Tuesday, February 21 , 1995 3:48 PM 

To: 'tbr' 

Cc: 'hchu' 

Subject: Hardware to run Flotherm 
Hi Tim s 

I am trying to determine which platform I should use to run Flotherm. Up to 
this point no one has been able to give me a decisive answer on the speed 
performance of the different machines that I am considering. I have decided 
the most cost effective way is to use one of the following system, since we 
already have them, 

1 . My existing Sun Space II w/Witek upgraded 

2. John Tang's Indigo with a R4000/100Mhz processor 

3. HP730 

Do you know which of these machine is the fastest? I did check with them 
regarding floating license. It will be the same price, except it will only be 
I seed per license instead of the 2 seeds for the node lock license. 

Thank you. 

Herman 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Tuesday, February 21, 1995 3:55 PM 
'Guillermo A. Loyola' 
'Ken Hsieh'; 'mikeh'; 'sysadm@bilbo' 
Re: Csyn Euterpe BOM 229 errors 


Follow Up Flag: Follow up 
Flag Status: Red 

Guillermo A, Loyola wrote (on Tue Feb 21): 


The SGI technical engineer told me that as long as it did not crash 
you system you can ignor them. 

I don't think that "not crashing the system" as in a kernel crash is an acceptable 
measure of the importance of the error. I think any errors should be tracked. 
We probably shouldn't do anything else for recoverable errors, but when we have 
a non-recoverable error, we should pay attention. The fact that the error happened 
while a user process was running, killing that process instead of crashing the 
system is irrelevant. In fact the "gmake" that died because of bilbo's memory 
error earlier today was doing an "official" software build, so it certanly was 
important for us. 

I had not read the first message carefully. I had come away with the 
impression the errors had been recoverable. Clearly the fact that 
there have been multiple errors, and that one of them was not 
recoverable, all on the same SIMM is already enough to say something 
is broken. Soft alpha hits won't cause multi-bit errors. 

I'm willing to wait to see iff when the error reoccurs before doing anything else, 
but we probably should press SGI or our memory vendor a little harder if it is 
still the case -as it used to be- that a significant number of the SGI machines 
get hard memory errors regularly (The old bilbo used to get them every 4-6 weeks). 

We have spares on hand, and a maintenance contract which should provide 
a replacement in a case like this. 

Ken, please talk to mikeh to get a replacemtn part and swap this one 
out for replacement. If we have further trouble after than we need to 
escalate. Regular failures as you describe hint at a design flaw to 
me. We certainly had this experience with the Challenge. It was a 
long time before they had a solid fix. 


Tim 
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From: torn (Tom Laidig (tau)) 

Sent: Tuesday, February 21, 1995 3:56 PM 

To: Tim B. Robinson' 

Cc: 'lisar (Lisa Robinson)'; 'tau' 

Subject: Re: Creole tape 

Tim B. Robinson writes: 


jtau wrote (on Tue Feb 21): 

j OK, the first error I encountered is when running 

j gmake -C proteus/verilog/libsrc everything 

j 1 get to where it's building some ikos thing, and it doesn't have 
j proteus/ikos/project.cfg, because I haven't included proteus/ikos in the 
j stuff I'm checking out. Is it OK to send proteus/ikos to the Creoles? 
| All of it, or part? 

|I think we should exclude this. There are files checked in there that 
|come direct from IKOS and could well be considered proprietary. 

Hmmm... I guess this means I need to do a build of everthing except iclib 
(is that right) in proteus/verilog/libsrc... right? 


j Also, last quarter we didn't send anything from mnemo, since it was just 
j starting to exist. I guess we should change that for this tape. For 
| reference, here's what we now do for the euterpe tree: 

[snip] 

I 

jMnemo should be exactly the same structure except that under verilog we 
|have *src' not 'bsrc' (which I see you have already accounted for). 

OK, lisar also mentioned that mnemo/verify/pci_examps should be 
excluded, since we bought them from someone. 

I 

JRemind me why we are excludeing the compass directory. . . 

We've been excluding all mobi layouts on the theory that that would 
provide too much information about the process. 


'V 
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From: woody (Jay Tomlinson) 

Sent: Tuesday, February 21, 1995 5:46 PM 

To: 'fwo (Fred Obermeier)' 

Cc: 'fwo'; 'hopper 1 ; 'tbr' 

Subject: Re: Csyn Euterpe BOM 229 errors 


Fred Obermeier wrote (on Tue Feb 21): 
Jay, 

As of bsrc/BOM 234, 1 don't see your fix to the OutputShortCheck problem 
on the xborff5df8s. Hopefully we'll see this fixed in the next BOM. 

Thanks, 
Fred. 

Yes it was fixed in 234+. It has not yet been released, 
jay 
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From: lisar (Lisa Robinson) 
Sent: Tuesday, February 21 , 1 995 6:02 PM 
To: 'billz'; 'jeffm'; 'mws'; 'tbr'; 'woody' 
Subject: BOM 234 


Failure so far: 

store_unique_0 (looks like X's) Failed 

memtest_0 (looks like X's) Failed 
gtlbmisseasy 0 Fai led 

dcacheeasy 0 (in fail loop) Failed 
dcacheharderu (in fail loop) Failed 
dcacheannoying_0 (in fail loop) Failed 
brmisseasy_0 (in fail loop) Failed 
brmisstest_0 (in fail loop) Failed 
icachemiss_0 Failed 
saaseasy_0 (in fail loop) Failed 
scaseasy O (in fail loop) Failed 
saastest_0 (in fail loop) Failed 
scastest_0 Failed 

Ran oks: 

testlOJ) Ran ok 
load_0 Ran ok 
ibuf_storeeasy_0 Ran ok 
itag_storeeasy_0 Ran ok 
dtag_storeeasy_0 Ran ok 
1tlb_0 Ran ok 
gtlb_0 Ran ok 
gtibaccess4_0 Ran ok 
dcachenoalloc_0 Ran ok 
icacheharder_0 Ran ok 
icacheannoying_0 Ran ok 
nbuseeasy_0 Ran ok 
nbfiilltest_0 Ran ok 
nbhiprio_0 Ran ok 
dramJoadO Ran ok 
dram_store_unique_0 Ran ok 
bdownharder O Ran ok 
synchtestO Ran ok 
sysprotol_l Ran ok 
sysproto2_l Ran ok 
cerbeasy_U Ran ok 

I am running (finally) memtest_0 in verilog now. The likedriverlog traces 
for these tests is in /s3/euterpe/verilog/bsrc/res/21295.89 16/results on rhodan. 

Jeff is taking a first pass look at the traces. 
Lisa R, 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Tuesday, February 21, 1995 11:13 PM 
'torn (Tom Laidig (tau)' 
'lisar (Lisa Robinson)'; 'tau' 
Re: Creole tape 


Follow Up Flag: Follow up 
Flag Status: Red 

tau wrote (on Tue Feb 21): 
Tim B. Robinson writes: 


jtau wrote (on Tue Feb 21): 

[ OK, the first error I encountered is when running 

| gmake -C proteus/veri log/1 ibsrc everything 

| I get to where it's building some ikos thing, and it doesn't have 
| proteus/ikos/projectcfg, because I haven't included proteus/ikos in the 
| stuff I'm checking out. Is it OK to send proteus/ikos to the Creoles? 
| All of it, or part? 

jl think we should exclude this. There are files checked in there that 
jcome direct from IKOS and could well be considered proprietary. 

Hmmm... I guess this means I need to do a build of everthing except iclib 
(is that right) in proteus/verilog/libsrc... right? 

iclib would be harmless, it is just a translation of our cells into 
the ikos netlist format. The stuff I'b be concerned about is all 
under proteus/ikos 

I 

| Also, last quarter we didn't send anything from mnemo, since it was just 

j starting to exist. I guess we should change that for this tape. For 

j reference, here's what we now do for the euterpe tree: 

[snip] 

I 

|Mnemo should be exactly the same structure except that under verilog we 
jhave 'src' not 'bsrc' (which I see you have already accounted for). 

OK, lisar also mentioned that mnemo/verify/pci examps should be 
excluded, since we bought them from someone. 

Yes, commercial stuff from Logic Modelling, Inc. 


j Remind me why we are excludeing the compass directory. . . 
We've been excluding all mobi layouts on the theory that that would 


Exhibit Cll 


Page 420 of 559 


provide too much information about the process. 
Ah, yes, and I think that should still hold. 
Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Tuesday, February 21, 1995 11:52 PM 

'paulb (Paul Berry)' 

'pandora' 

Hermes with Cronus 


Paul Berry wrote (on Tue Feb 21) : 

Does the Hermes channel whose master is a Cronus 

rather than a Euterpe run at a proportionately slower speed? 

That is, are the statements about 1 GHz rates on the Hermes channel 

applicable only to Euterpe? 

On euterpe, the max Hermes clock is one half the sofa clock, so a 1 . 08GHz euterpe has a 
504MHz max Hermes clock which corresponds to a data rate of 1.08 GB/s in each direction 
since data is transferred on both edges of the Hermes clock. 

The target speed for Cronus is 400MHz. If we only allowed a 200MHz Hermes clock the 
latency to the secondary cache in the Mnemosynes would be unacceptable (probably worst 
than a typical system's latency to DRAM), so we are going to change the design to fix the 
Hermes clock equal to the SOFA clock, ie nominally 400MHz. This gets us back to within 
20% in both latency and bandwidth to what we had in Euterpe (at some cost in additional 
design work) . We are fixing the rate (rather than allowing the flexible rations we have 
on Euterpe) to avoid the need for a second PLL in the system since we will not be 
integrating PLLs onto Cronus. (There will be a single PLL on the PCB to generate the 
400MHz (ish) clock to the processor.) 

(I copied Pandora since this seemed to be an item of general 
interest . ) 


Tim 
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From: tbr 

Sent: Wednesday, February 22, 1995 12:20 AM 

To: 'hopper (Mark Hofmann)' 

Subject: CSM rules 

Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofmann wrote (on Tue Feb 21): 


Hi, 

I've spoken with most of the CAD folk now, with Geert and Drew and 
Mike and Orlando. The consensus seems to be that it would be okay 
at worst and a good thing at best if we switch to integer design rules. 

Can you give a short explanation? Are we doing floating point DRC's? 
Tim 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, February 22, 1995 12:27 AM 

To: 'Tim B. Robinson' 

Subject: Re: CSM rules 

Tim B. Robinson writes: 
Mark Hofmann wrote (on Tue Feb 21): 
Hi, 

I've spoken with most of the CAD folk now, with Geert and Drew and 
Mike and Orlando. The consensus seems to be that it would be okay 
at worst and a good thing at best if we switch to integer design rules. 

Can you give a short explanation? Are we doing floating point DRC's? 

Actually no (except perhaps with Dracula). We were scaling the Vlsimm 

parts by 10 to avoid doing floating point checks. The .ly and xif files 

were being stored as reals (actually in ascii). The difficulty is that 

all our previous process were integer and our tools were oriented 

this way. As we converted to being able to handle reals we noticed 

all kinds of little limitations. For instance Geert had problems regenerating 

the baseplate because M4 does not handle reals. It seemed like instead 

of constantly patching tools we should take the integer route here. 

The mask folks did not have a problem with this since they used such 

udr schemes (20 to the micron, for example for Mobi) for our past processes. 

They preferred 10 to the micron for CSM since it's easy to mentally 

move the decimal point and get the actual micron dimension. 

-hopper 
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From: wampler (Kurt Wampler) 

Sent: Wednesday, February 22, 1995 9:27 AM 

To: 'tor' 

Subject: Re: M2 obs fixes 
tbr writes: 


>The .checkoutrc is never executed in a snapshot update because we 
>bring out the BOM at the toplevel and run the top level Makefile. 
>This must imply that something is missing from the top level Makefile. 

> 

>Is there a specific order wrt other things in the database that this 
>make must be run, or can it be done in isolation any time? 

I looked at proteus/Makefile, and indeed it seems to be missing a 
make in proteus/clockbias. The only thing this make accomplishes is 
the compilation of 3 "C" programs, so it should be done early - it 
would even be safe to put it first in the Makefile. It needs to be 
done before euterpe/clockbias, mnemo/clockbias, or any other chip 
clockbias makes are executed. 

>OK, I'd like to fix the top level Makefile, then get a new BOM 

> 

>I see there have been edits to the gtlb to fix csyn problems, 

>and edits to the PLL layouts. Does anyone see a reason not to pick 

>these up? 

There was a hwc mask update for pl_eus, and I also removed a "-f ' switch 
on the hwcroute invocation for gardswarts. It should be safe to pick up 
these changes in the snapshot. 

-Kurt 
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From: 
Sent: 
To: 

Subject: 


craig 

Wednesday, February 22, 1995 10:24 AM 
'tbr 1 

Re: Hermes with Cronus 


Given that Mnemosyne is operating at half the rate of its original target, I think it's 
also worth considering such a change in Mnemosyne itself. As to the rate flexibility on 
Cronus, it's worth considering a power-of-two rate control, which could also avoid a PLL - 
also the higher rate Hermes channel should be considered for a rev of Euterpe (such as the 
Cronus ->MOBIMOS remap part) . 


Craig 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 22, 1995 10:38 AM 

To: 'tbr* 

Subject: disc space 

tim, 

you mentioned last week that we might have some more 
disc capacity this week if i remember right i've been trying to compile 
the mnemo design to add cerberus signames at the toplevel 
but i fear that i dont have enough disc space for both a euterpe tree 
and a mnemo tree, i cuurently am ussing over 900 M bytes in my home 
partition. 

by the way what is dave user name i wanted to email him about the pci 
directory, my gmake sim run has problems when i gets to compiling 
taht directory for mnemo? 

dickson 
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Sent: 
To: 

Subject: 


From: 


tbr 

Wednesday, February 22, 1995 10:43 AM 
'hopper (Mark Hofmann)' 
Re: CSM rules 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Wed Feb 22): 
Tim B. Robinson writes: 
Mark Hofmann wrote (on Tue Feb 21): 


I've spoken with most of the CAD folk now, with Geert and Drew and 
Mike and Orlando. The consensus seems to be that it would be okay 
at worst and a good thing at best if we switch to integer design rules. 

Can you give a short explanation? Are we doing floating point DRC's? 

Actually no (except perhaps with Dracula). We were scaling the Vlsimm 

parts by 10 to avoid doing floating point checks. The .ly and .cif files 

were being stored as reals (actually in ascii). The difficulty is that 

all our previous process were integer and our tools were oriented 

this way. As we converted to being able to handle reals we noticed 

all kinds of little limitations. For instance Geert had problems regenerating 

the baseplate because M4 does not handle reals. It seemed like instead 

of constantly patching tools we should take the integer route here. 

The mask folks did not have a problem with this since they used such 

udr schemes (20 to the micron, for example for Mobi) for our past processes. 

They preferred 10 to the micron for CSM since it's easy to mentally 

move the decimal point and get the actual micron dimension. 

Sounds good to me! 


Hi, 


Tim 
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From: 


tbr 


Sent: 


Wednesday, February 22, 1995 10:47 AM 
'wampler (Kurt Wampler)' 
Re: M2 obs fixes 


To: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Wed Feb 22): 
tbr writes: 

>The .checkoutrc is never executed in a shapshot update because we 
>bring out the BOM at the toplevel and run the top level Makefile. 
>This must imply that something is missing from the top level Makefile. 


>Is there a specific order wrt other things in the database that this 
>make must be run, or can it be done in isolation any time? 

I looked at proteus/Makefile, and indeed it seems to be missing a 
make in proteus/clockbias. The only thing this make accomplishes is 
the compilation of 3 "C" programs, so it should be done early — it 
would even be safe to put it first in the Makefile. It needs to be 
done before euterpe/clockbias, mnemo/clockbias, or any other chip 
clockbias makes are executed. 

I'd already put it in, a little later in the Makefile, but everything 
here gets made before any chip specific stuff, so that should be fine. 

>OK, I'd like to fix the top level Makefile, then get a new BOM 


>I see there have been edits to the gtlb to fix csyn problems, 

>and edits to the PLL layouts. Does anyone see a reason not to pick 

>these up? 

There was a hwc mask update for pl eus, and I also removed a "-f ' switch 
on the hwcroute invocation for gards warts. It should be safe to pick up 
these changes in the snapshot 


> 


> 


Thanks. 
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From: tbr 

Sent: Wednesday, February 22, 1995 11:26 AM 

To: 'dickson (Richard Dickson)' 

Subject: disc space 

Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Wed Feb 22): 
tim, 

you mentioned last week that we might have some more 
disc capacity this week if i remember right, i've been trying to compile 
the mnemo design to add cerbems signames at the toplevel 
but i fear that i dont have enough disc space for both a euterpe tree 
and a mnemo tree, i cuurently am ussing over 900 M bytes in my home 
partition. 

We are scheduled to get some space in today. We'll probably be taking 
staypuft and gamoora down today to add it. 

by the way what is dave user name i wanted to email him about the pci 
directory, my gmake sim run has problems when i gets to compiling 
taht directory for mnemo? 

dbulfer, however you may want to check with age because he's working 
there too, more with the top level. 

Tim 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, February 22, 1 995 1 1 :36 AM 

To: 'hardheads' 

Subject: 5pm disturbance: Exlax and Shiftpim 
...have been updated. 

Exlax now produces .flipx .directives for even numbered dout buffers 
when they are placed side-by-side. This should reduce the metal 2 wire 
length during hook-up by Gards route. (It was noted that some Gards 
routes of Exlax arrays on Euterpe had a large number of short metal 2 stubs.) 

Shiftpim has been updated to properly preifx ,flipXX directives when 
they are present in .pirn files. 

As usual, please let me know if I've broken anything. 

-thanks, 
hopper 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 22, 1 995 1 1 :57 AM 

To: 'geert'; 'hopper*; 'for' 

Subject: ged2lvs problem 


you" all 

have you been having this problem ? i ' ve had it since late last nite . 

<lnk>#l ERROR (145): Pin name does not exist 
Drawing: " TLBXR7 4 COL " . SPICE .1.1 

No parameters 
Body: "FLAG" ( Path= " 25P" ) 
Unfound pin: »VREF_0P250V" 

Drawing : "TLBXRABLK" . SPICE . 1 . 1 

No parameters 
Body: " TLBXR74COL" (Path= M lP") 
Pins of the body: 

"VRR"<2. .0> 

"VII" 

" SAOUT_AD0 PH " < 7 3 . . 0 > 
" SAOUT_AND0 PH " < 7 3 . . 0 > 
" XORRD_A0 PF " < 7 3 . . 0 > 
"DAT_A0PF"<73 . . 0> 
"WLXOR_AB0PM"<63 . . 0> 
"VPPHI_VW" 
"VBBN_VW" 
"TAIL_VW"<9. ,0> 
"WE_AND0PH"<9. . 0> 
"WE_AD0PH"<9. .0> 
M VREF_0P" 

"RWL A2P375V"<63 . .0> 


i was running gmake rich_euterpegards . i guess it was compiling the custom blocks ? 

dickson 
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From: woody (Jay Tomlinson) 

Sent: Wednesday, February 22, 1995 12:00 PM 

To: 'dbulfer (David Bulfer)' 

Cc: Tim B. Robinson' 

Subject: Re: Pandora Cerberus addresses 


David Bulfer wrote (on Wed Feb 22): 
That does remind me though, that we need to redefine the Hermes pin out 
for Pandora and make the next Hestia PCB consistent. We need pairs to 
route to adjacent pins on the same side of the connector rather than 
opposite sides. How should I submit this change request? Gnats? 

David 


Is this what you had in mind? This pin assignment frees up a bunch of pins sine 

the GND is 1 :2 instead of 1 : 1 . 

jay 

iflllllliiiliii!iillililfiililliiifliil!iii!iiilliillltlllflilii!tiiillliili!til 

if Hermes Connector 0 

p370_00004_0000 heconn ( { 

clkin0_ABD0P700MV, dinO_ABDOP700MV[0], // pin 80,79 
clkinO„ABNDOP700MV, din0_ABND0P700MV[0], 
GND, GND, 

dinO_ABDOP700MV[l ], dinO_ABDOP700MV[2], 
din0_ABND0P700MV[l], din0_ABND0P700MV[2], 
GND, GND, //pin 70,69 

din0_ABD0P7O0MV[3], dinO_ABD0P700MV[4], 
din0_ABNDOP700MV[3j, din0_ABND0P700MV[5j, 
GND, GND, 

din0_ABD0P700MV[5], dinO_ABD0P700MV[6], 
dinO_ABNDOP700MV[5], din0^ABND0P700MV[6], //pin 60,59 
GND, GND, 

din0_ABD0P700MV[7], dout0_ABD0P700MV[7], 
din0_ABND0P700MV[7], dout0_ABND0P700MV[7], 
GND, GND, 

dout0_ABD0P700MV[6], dout0_ABD0P700MV[5], //pin 50,49 
dout0_ABND0P700MV[6], dout0_ABND0P700MV[5], 
GND, GND, 

dout0_ABD0P700MV[4], dout0_ABD0P700MV[3], 
dout0_ABND0P700MV[4], dout0_ABND0P700MV[3], 
GND, GND, //pin 40,39 

dout0_ABD0P700MV[2], dout0_ABD0P700MV[l ], 
dout0_ABND0P700MV[2] , dout0_ABND0P700M V[ 1 ] , 
GND, GND, 

dout0_ABD0P700MV[0], clkout0_ABD0P700MV, 
dout0_ABND0P700MV[0], clkout0_ABND0P700MV, //pin 30,29 
GND, GND, 

clk54m_ABD0P700MV, NChcconn25, 
clk54m ABNDOP700MV, NChcconn23, 
GND, GND, 

NChcconn20, NChcconn 1 9, //pin 20, 1 9 
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NChcconn 18, 
NChcconn 1 6, 
NChcconn 14, 
NChcconn 12, 
NChcconn 10, 
NChcconn8, 
NChcconn6, 


NChcconn 17, 
NChcconn 1 5, 
NChcconn 13, 
NChcconnll, 

NChcconn9, //pin 10, 9 

NChcconn7, 

NChcconn 5, 


NChcconn4, // SN3 : For bring-up, to be able to force euterpe to boot from cerberus 
GND, 

sc_am, sd_bm, //pin 3,2 

// pin 1 

GND // >» *** reserved for expansion box power control *** 

}); 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hchu (Herman Chu) 

Wednesday, February 22, 1995 12:09 PM 
'geerf; 'tor'; 'bill'; 'noeP; 'trancy'; 'dbulfer'; 'tbe' 
'hchu'; 'pandora'; 'al' 
Cronus 150wattTab Frame 


Based upon previous test results of the Eu/Ca Tab frame and a detail computer modelling 
results, the current Tab frame design will not survive thermally for the 150 watt Cronus 
device for the environmental specifications that it has to meet. 

Possible solutions: 

1. Fatter traces coupled with more even power distribution over the entire 
Tab frame. 

2 . Implementation of thermal conduction path from the Tab frame to heat sink 
base and may be to the PCB also. 

Please let me know if electrically these options can be implemented. 


Begin Included Message 

>From hchu Thu Sep 22 11:18:50 1994 
Date: Thu, 22 Sep 94 11:18:47 PDT 
From: hchu (Herman Chu) 
To: noel, trancy 

Subject: TAB Lead Steady-state Thermal Testing /Ana lysis 
Cc: hchu, hestia, euterpe 
Content -Length: 2187 

1 have performed testing on the TAB leads in an isolated bare TAB frame, that is no 
die/ST, no PCB, and no heat sink attached. I tried to measure temperature as close to the 
powered leads as possible while minimizing the disturbance to the overall thermal 
characteristics of the TAB frame (The Uncertainty Principle) . The current thermal and 
electrical test equipments that we have are not adequate for precise measurements for this 

level of packaging test, nonetheless, with the limited time that I have for testing and 
evaluation, the results provided me with valuable ball park estimates of the thermal 
performance of the leads under intended operating 

environement . 

The lead temperature was not measured directly, therefore the lead temperature results 
presented below are based upon test results and analytical extrapolations. 

2 cases were tested. The first case was tested with only 1 lead powered on, and in the 
seconde case 5 leads were powered on. 


Herman 


Results : 


The estimated lead temperatures are presented in the following table: 


Test Case 


1- Single Lead 


2- 5 Leads 


T surrounding 


50 deg C 


50 deg C 
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Current /Lead 0.33 Amp 0.3 3 Amp 

Estimated 5 9 deg C 76 deg C 

Lead Temperature 


Discussions : 

1. Temperatures were measured at other locations that were placed 
gradually 

away from the powered leads. Based upon those results, it was clear 

that 

the polyimide will not provide efficient thermal spreading if a lot of 
powered leads will be concentrated together. 

2. There was a significant lead temperature difference (17 deg C) between 
a 

single lead powered on case and 5 leads powered on case. There are two 
corner sections in the latest Eu TAB frame layout that in each have 32 
power leads congregated together right next to each other. This might 

be a 

potential thermal problem. 

3 . I performed the test applying a range of current through the leads . 
If 

anyone is interested in that data please let me know. 

Please let me know if you guys need clarification on my test setup and 
assumptions. 

Herman 


End Included Message 
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From: craig 

Sent: Wednesday, February 22, 1995 12:10 PM 

To: 'bill dbulfer geert hchu noel tbe tbr trancy' 

Cc: 'a! pandora' 

Subject: Re: Cronus 150watt Tab Frame 


It should be clear that Cronus needs a different tab frame than Euterpe, as it has a 
different die size (and perhaps a different pin- out) . 

Craig 
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From: dbulfer (David Bulfer) 

Sent: Wednesday, February 22, 1 995 1 2:22 PM 

To: 'Jay Tomlinson' 

Cc: 'tbr (Tim B. Robinson)'; 'ras (Bob Sutherland)'; 'd Bulfer (David Bulfer)'; 'pandora'; 'hestia' 

Subject: Re: Pandora Cerberus addresses 


I think that this is a more appropriate pin out for the Hermes connector. Especially with 
the straddle mount version that we need for Pandora, it should give improved common mode 
rejection with easier routing. I suggest that we adopt it for Pandora and Hestia? 

Comments? 

David 


P.S. You might also note that it frees up a bunch of pins --we have 

one ground for each pair rather than one per wire. (Since we are 
differential, there should be zero current in the shield pins.) 
We can use four of these pins for module addressing. 

> 

> Is this what you had in mind? This pin assignment frees up a bunch of 
pins sine 

> the GND is 1:2 instead of 1:1. 

> jay 

////////////////////////////////////////////////////////////////////////// 
////// 

> // Hermes Connector 0 

> p370_00004 0000 heconn ( { 

> clkinO_ABDOP700MV, 
80,79 

> clkin0_ABND0P700MV, 

> GND , GND , 

> dinO_ABDOP70 0MV[l] , 

> dinO_ABNDOP7 00MV[l] , 

> GND , GND , 


dinO_ABDOP700MV[0] , 

dinO_ABNDOP7 00MV[0] , 

dinO_ABDOP7 00MV[2] , 
din0_ABNDOP700MV[2] , 
// pin 


// pin 


60,59 


50,49 


40, 39 


30,29 


din0_ABD0P700MV[3] , 
dinO_ABNDOP7 0 0MV[3] , 
GND, GND, 

dinO_ABDOP700MV[5] , 
din0_ABND0P700MV[5] , 

GND, GND, 

dinO_ABD0P7 00MV[7] , 
din0_ABND0P7 0 0MV[7] , 
GND, GND, 

dout0_ABD0P700MV[6] , 

dout0_ABND0P700MV[6] , 
GND, GND, 

dout0_ABD0P7 0 0MV[4] , 
dout0_ABND0P7 00MV[4] , 
GND, GND, 

dout0_ABD0P700MV[2] , 
dout0_ABND0P7 0 0MV[2] , 
GND , GND , 

dout0_ABD0P700MV[0] , 
dout0_ABND0P700MV[0] , 

GND , GND , 

clk54m_ABD0P700MV, 
clk54m_ABND0P7 00MV, 
GND, GND, 


din0_ABD0P700MV[4] , 
din0_ABND0 P7 0 0MV [ 5 ] , 

dinO_ABDOP700MV[6] , 
din0_ABND0P700MV[6;j , //pin 


dout0_ABD0P7 0 0MV[7] , 
dout0_ABND0P700MV[7] , 

dout0_ABD0P7 0 0MV[5] , //pin 

dout0_ABND0P700MV[5] , 

dout0_ABD0P7 0 0MV[3] , 
dout0_ABND0P700MV[3] , 
//pin 

doutO_ABDOP7 0 0MV[l] , 
dout0_ABND0P7 0 0MV[l] , 

c Ikout 0_ABD 0 P7 0 0MV , 
clkout0_ABND0P7 0 0MV, //pin 

NChcconn25 , 
NChcconn2 3 , 
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NChcconn20, 


NChcconnl9 / 


//pin 


NChcconnl8 , 
NChcconnlS , 
NChcconnl4 , 
NChcconnl2 , 
NChcconnlO , 

NChcconnS , 

NChcconn6, 


NChcconnl7, 
NChcconnlS, 
NChcconnl3 , 
NChcconnll, 
NChcconnS 

NChcconn7 , 

NChcconnB, 


//pin 10, 


> NChcconn4, // SN3 : For bring-up, to be able to force 
euterpe to boot from cerberus 

> GND , 

> sc_am, sd_bm, //pin 3,2 
// pin 1 

> GND // »> *** reserved for expansion box 
power control *** 

} ); 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, February 22, 1995 12:26 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/sr BOM 53 . 0 initiated by dickson completed @ Wed Feb 22 
10:25:10 PST 1995 with exit status 1.. chip 

lock read: File exists 


Exhibit Cll 


Page 440 of 5 


From: 
Sent; 
To: 

Subject: 


dickson (Richard Dickson) 
Wednesday, February 22, 1995 12:43 PM 
'geeif ; 'hopper'; 'tbr' 
releasebom problems 


you' all 


i was releasebom' ing my latest placement changes to sr and got this .... 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

Xlib: connection to "clio:0.0" refused by server 
Xlib: Client is not authorized to connect to Server 

Test: Error in opening display = clio:0.0 GARDS GPLACE 7.126 -- General Placer Copyright 
(c) 1995 SILVAR-LISCO. All rights reserved. 
Design: sr-passl Started at: 95/02/22 10:22:40 


GPLACE Version 7.1.2 6 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components. . . 

Loading nets . . . 

Loading logical types. . . 

Processing physical types... 

Loading cell_types. . . 

Creating net-comp xref table... 

gmake[2]: *** [gards/sr-passl .nof ] Error 1 

gmake [2]: Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/sr 1 
gmakeEl]: *** [sr-base . short . nets] Error 1 
gmake [1] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/sr 1 
gmake: *** [srgards] Error 1 

has this been bothering anyone else ??? 


dickson 
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From: craig (Craig Hansen) 

Sent: Wednesday, February 22, 1995 1:10 PM 

To: 'bill'; 'dbulfer'; 'geerf; 'fichu'; 'noel'; 'the'; 'tbr'; 'trancy' 

Cc: 'al 1 ; 'pandora' 

Subject: Re: Cronus 150watt Tab Frame 


It should be clear that Cronus needs a different tab frame than Euterpe, as it has a 
different die size (and perhaps a different pin-out) . 

Craig 
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To: 


Cc: 

Subject: 


Sent: 


From: 


tbr 

Wednesday, February 22, 1995 1:56 PM 
'dickson (Richard Dickson)' 
'geeif; 'hopper' 
ged2lvs problem 


Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Wed Feb 22): 
you'all 

have you been having this problem ? i've had it since late last nite. 

<lnk>#l ERROR(145): Pin name does not exist 
Drawing: "TLBXR74COL".SPICRI.l 

No parameters 
Body: "FLAG" (Path="25P") 
Unfoundpin: "VREF_0P250V" 

Drawing: 'TLBXRABLK". SPICE. 1.1 

No parameters 
Body: "TLBXR74COL" (Path="lP") 
Pins of the body: 

"VRR"<2..0> 

"VII" 

"SAOUT_AD0PH"<73..0> 

"SAOUT_AND0PH"<73..0> 

"XORRD_A0PF"<73..0> 

"DAT_A0PF"<73..0> 

"WLXOR_AB0PM'*<63..0> 

"VPPHI VW" 

"VBBNVW" 

"TAIL_VW"<9..0> 

"WE_AND0PH n <9..0> 

"WE_AD0PH"<9..0> 

»'VREF_0P" 

"RWL_A2P375V"<63..0> 


i was running gmake rich_euterpegards. i guess it was compiling the custom blocks ? 

Which proteus are you using? There have been some edits to fix csyn 
things which have not bee propagated to the snapshot yet. 


Tim 
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From: dickson (Richard Dickson) 

Sent: Wednesday, February 22, 1995 1:57 PM 

To: tbr 1 

Subject: proteus 

tim, 

i'm still pointing at /u/chip/euterpe/proteus 
dickson 
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Sent: 
To: 

Cc: 


From: 


Subject: 


tbr 

Wednesday, February 22, 1995 2:03 PM 
'dickson (Richard Dickson)' 
'geerf; 'torn'; 'hopper" 
releasebom problems 


Follow Up Flag: Follow up 
Flag Status: Red 

Richard Dickson wrote (on Wed Feb 22): 
you'all 

i was releasebom 'ing my latest placement changes to sr 
and got this .... 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 

gardsconfig_3 
Checked out one user token of a gardsconfig_3 license. 

Xlib: connection to "clio:0.0" refused by server 

Xlib: Client is not authorized to connect to Server 

Test; Error in opening display = clio:0.0 

GARDS G PLACE 7. 126 -- General Placer 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 

Design: sr-passl Started at: 95/02/22 10:22:40 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 
Loading components... 
Loading nets- 
Loading logical types... 
Processing physical types... 
Loading celljypes... 
Creating net-comp xref table... 
gmake[2]: *** [gards/sr-passl.nof] Error I 

gmake[2]: Leaving directory '/N/auspex/root/slO/chip/euterpe/verilog/bsrc/sr' 
gmake[l]: *** [sr-base.short.nets] Error 1 

gmake[l]: Leaving directory ^/N/auspex/root/slO/chip/euterpe/verilog/bsrc/sr' 
gmake: *** [srgards] Error 1 

has this been bothering anyone else ??? 

I guess it should have been bothering torn. I'll check if his machine 
is alive. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, February 22, 1995 2:03 PM 

To: 'dickson (Richard Dickson)' 

Cc: 'geert'; 'torn'; 'hopper' 

Subject: release bom problems 


Richard Dickson wrote (on Wed Feb 22) : 
you 'all 

i was releasebom' ing ray latest placement changes to sr 
and got this .... 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

Xlib: connection to "clio:0.0" refused by server 
Xlib: Client is not authorized to connect to Server 
Test: Error in opening display = clio:0.0 
GARDS GPLACE 7.126 -- General Placer 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: sr-passl Started at: 95/02/22 10:22:40 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components . . . 

Loading nets . . . 

Loading logical types . . . 

Processing physical types... 

Loading cell_types. . . 

Creating net-comp xref table. . . 

gmake [2] : *** [gards/sr-passl . nof ] Error 1 

gmake [2] : Leaving directory 
" /N/auspex/root/ slO/chip/euterpe/verilog/bsrc/sr 1 

gmake [1] : *** [ sr- base . short . nets] Error 1 

gmake [1] : Leaving directory 
VN/auspex/root/slO/chip/euterpe/verilog/bsrc/sr 1 

gmake: *** [srgards] Error 1 

has this been bothering anyone else ??? 
I guess it should have been bothering torn. I'll check if his machine is alive. 
Tim 
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From: tbr 

Sent: Wednesday, February 22, 1995 2:13 PM 

To: 'dickson (Richard Dickson)' 

Subject: proteus 
Follow Up Flag: Follow up 
Flag Status: Red 

Richard Dickson wrote (on Wed Feb 22): 
tim, 

i*m still pointing at /u/chip/euterpe/proteus 
Change to using the snapshot, 
/n/ au spex/s4 1 /euterpe-snapshot/euterpe/proteu s 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, February 22, 1995 2:19 PM 

To: •geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/sr BOM 54.0 initiated by dickson completed @ Wed Feb 22 
12:16:37 PST 1995 with exit status 0.. chip 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, February 22, 1995 2:58 PM 

To: , geert@rhea' 

Subject: pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/cc BOM 64.0 initiated by dickson completed @ Wed Feb 22 
12:56:25 PST 1995 with exit status 0.. chip 

lock read: File exists 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Wednesday, February 22, 1995 3:05 PM 
'geert'; 'hopper'; 'tbr' 
releasebom cc 


you' all 


my luck seems to be bad this morning . . . 

HOME- /n/auspex/ slO/chip/ euterpe/ tools 
LM_LICENSE_FILE= /n/auspex/ si 0/chip/eute 

rpe/tools/sl/license/license.dat DISPLAY=clio : 0 . 0 SL_TOTAL_DURATION=5 00 CHIPROOT 
=/n/auspex/slO/chip/euterpe /n/auspex/ slO/chip/euterpe/ tools /si /bin/ invoke 
gplac 

e cc-passl -listing cc-passl . gplace . lis -cmdin cc-passl . gplace . nic -colorin cc-p 
assl . gplace . mobi234 - inbat 1 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

XIO: fatal IO error 32 (Broken pipe) on X server " (null) " 

after 0 requests (0 known processed) with 0 events remaining. 

The connection was probably broken by a server shutdown or KillClient. 

GARDS GPLACE 7.126 General Placer 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: cc-passl Started at: 95/02/22 12:52:20 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found,- select by hierarchy disabled. 

Loading components . . . 

Loading nets . . . 

Loading logical types . . . 

Processing physical types... 

Loading cell_types . . . 

Creating net-comp xref table... 

gmake[2]: *** [gards/cc-passl .nof ] Error 1 

gmake [2] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc • 
gmake [1] : *** [cc-base . short . nets] Error 1 
gmake [1] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/cc 1 
gmake: *** [ccgards] Error 1 

is this because staypuft just went down ??? 


dickson 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Wednesday, February 22, 1995 3:55 PM 
'dickson (Richard Dickson)' 
'geert'; 'hopper' 
releasebom cc 


Follow Up Flag: Follow up 
Flag Status: Red 

Richard Dickson wrote (on Wed Feb 22): 
you'all 

my luck seems to be bad this morning ... 

HOME=/n/auspex/s 1 0/chip/euterpe/tools LM_LICENSE_FILE=/n/auspex/s 1 0/chip/eute 
rpe/tools/sl/license/license.dat DISPLAY=clio:0.0 SL_TOTAL_DURATION=500 CHIPROOT 
=/n/auspex/s 1 0/chip/euterpe /n/auspex/s 1 0/chip/euterpe/tools/sl/bin/invoke gplac 
e cc-passl -listing cc-passl.gp lace. lis -cmdin cc-passl. gplace.nic -colorin cc-p 
assl.gplace.mobi234 -inbat 1 

Requires a minimum license of xgplacel 3 or gardsl_3 . 
Applicable licenses available at your installation : 

gardsconfigJ3 
Checked out one user token of a gardsconfig_3 license. 

XIO: fatal lO error 32 (Broken pipe) on X server "(null)" 

after 0 requests (0 known processed) with 0 events remaining. 

The connection was probably broken by a server shutdown or KillClient. 
GARDS GPLACE 7.126 - General Placer 
Copyright (c) 1995 SILVAR-USCO. All rights reserved. 
Design: cc-passl Started at: 95/02/22 12:52:20 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components... 

Loading nets... 

Loading logical types... 

Processing physical types... 

Loading cell_types... 

Creating net-comp xref table... 

gmake[2]: *** [gards/cc-passl.nofj Error 1 

gmake [2]: Leaving directory '/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc' 
gmake[l]: *** [cc-base.short.nets] Error 1 

gmake [ 1 ] : Leaving directory ' /N/auspex/root/s 1 0/ch ip/euterpe/ veri log/bsrc/cc' 
gmake: *** [ccgards] Error 1 

is this because staypuft just went down ??? 

staypuft is still up, so it's not that. This looks like a problem 
with clio again. 
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Be aware that the disks are in and both staypuft and gamorra will be 
going down shortly 

Tim 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, February 22, 1995 3:55 PM 

To: 'dickson (Richard Dickson)' 

Cc: 'geert'; 'hopper 1 

Subject: releasebom cc 


Richard Dickson wrote (on Wed Feb 22) : 
you' all 

my luck seems to be bad this morning . . . 

HOME =/n/auspex/slO/chip/ eut erpe/tools 
LM_LICENSE_FILE= /n/auspex/ S10 /chip/eute 

rpe/ tools /si /license/ license.dat DISPLAY=clio : 0 . 0 SL_TOTALJDURATION=500 CHIPROOT 

=/n/auspex/slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke gplac 

e cc-passl -listing cc-passl . gplace . lis -cmdin cc-passl . gplace . nic -colorin cc-p 

assl .gplace .mobi234 -inbat 1 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

XIO: fatal 10 error 32 (Broken pipe) on X server "(null)" 

after 0 requests (0 known processed) with 0 events remaining. 

The connection was probably broken by a server shutdown or KillClient . 

GARDS GPLACE 7.126 -- General Placer 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: cc-passl Started at: 95/02/22 12:52:20 

GPLACE Version 7.1.26 of September 9, 1994 

No component hierarchy found; select by hierarchy disabled. 

Loading components . . . 

Loading nets. . . 

Loading logical types . . . 

Processing physical types... 

Loading cell_types . . . 

Creating net-comp xref table... 

gmake[2]: *** [gards/cc-passl . nof ] Error 1 

gmake [2]: Leaving directory 
* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc 1 

gmakeflj: *** [cc -base . short . nets] Error 1 

gmake [1] : Leaving directory 
* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc ' 

gmake: *** [ccgards] Error 1 

is this because staypuft just went down ??? 
staypuft is still up, so it's not that. This looks like a problem with clio again. 
Be aware that the disks are in and both staypuft and gamorra will be going down shortly 
Tim 
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From: torn (Tom Laidig (tau)) 

Sent: Wednesday, February 22, 1995 5:22 PM 

To: 'Mark Hofmann' 

Cc: 'hardheads'; 'tau' 

Subject: Re: IMMINENT DECISION: CSM Design rule units 


Mark Hofmann writes: 
I 

| IMMINENT DECISION: CSM Design rule units 
I 

j The CSM design rules are expressed in microns, with tenth micron 

j accuracy. Originally, design flows were set up to run with these native 

tenth 

(micron rules. However, a number of tools and preprocessors (like M4) do 
j not handle real numbers well or at all. There is some worry that 
designs 

done in real units may get corrupted in translation to integer units. 

For these reasons it has been proposed that 1 micron in the CSM rules 
map to 10 DBUs (database units) . This allows for integer-only 
arithmetic , 

precludes the chance of truncation errors, and is similar to the 
mapping already done for both the Roller's and MOBI processes. 

The CAD group will re-map all existing CSM layouts to these units. 

This decision will become final on 27 Feb 95. 

Due to the changeover to the Gregorian calendar, today has been declared to be the 2 7th of 
February . 

OK, actually, we decided we just couldn't wait that long, and we believe we've already 
polled enough relevant people to be able to make the change. 

Sometime after 10pm tonight, I will process all cells in mdunit /atlas/compass/layouts to 
scale them to the new coordinate system. I will also modify 
technology/ csm/ compass /vl si .boo to adjust its snapping grid, and modify 
technology/csm/hspice/models to set the appropriate lvs scale factor. 

Layout folks should try to check in all important layouts before leaving tonight, and exit 
from compass. Tomorrow morning, everything should be ready, even when Mikey comes in. 

I believe Dave has a new DRC flow prepared for the modified scaling, which he should be 
able to install pretty soon. 

Are we having fun yet? 
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From: 


tbr 


Cc: 


Sent: 


To: 


Wednesday, February 22, 1995 9:03 PM 
'gmo' 

'pandora@news' 


Follow Up Flag: Follow up 
Flag Status: Red 


Guillermo A. Loyola wrote (on Tue Feb 21): 


I think we are mixing several different discussions here which don't necessaraly 
belong together. 

First question is how to connect a ROM to Cerberus, which in an implementation 
of Terpsichore without an onboard ROM interface is of paramount importance; 
in an MPP application is quite important so you can share the ROM; but for 
Euterpe in Hestia or Pandora is a lot less interesting. 

The more interesting question is How do we debug a Hestia-like box using 
Pandora? I would say that the minimum requirements are 1. To be able to reset 
Hestia * without* having to reset Pandora at the same time, and 2. To be able 
to read and write Cerberus registers in Hestia's devices from Pandora. Although 
not a "minimum" requirement, we have been assuming that we will have (at least 
in the pre-Pandora cross-development environment) 3. A promiscous-master-slave 
interface that allows us to snoop on all Cerberus transactions and also to 
respond to any unused Cerberus address. 

A direct connection between Pandora's Cerberus bus and Hestia's Cerberus bus 
allows us to do #2 above, but not #1 and certanly not #3; so it is only 
mildly instersting. 

I disagree on this one, and Craig has already pointed out that the 
provision of both logic clear and circuit reset bits in octlet 6 of 
all Cerberus devices is designed to allow any set of devices to be 
reset independent of any others. It should therefore be quite 
possible to reset Hestia independent of Pandora in a single Cerberus 
configuration. 

What Dave had talked about a couple of weeks ago sounded to me like a plan 
to implement an interface that would give us all 3 directly in Mnemo, which 
is fine by me, but only if it is easy to do with a minumal impact on Mnemo's 
schedule; and it certanly does not require Mnemo to have a ROM interface. 

Since then, Craig pointed out that besides being able to read and 
write the Hestia registers from pandora, the main function we would 
want is to be able to emulate the boot rom. Now, while we can't 
access the whole Pandora boot rom via the Cerberus space (because the 
Cerberus address space of a single device is limited to 16 bits) 
we can get to a large chunk of it, presumably enough to be able to 
emulate the Hestia boot. We have not gone back to add a full master 
interface on Mnemo. That would add considerable complexity, and area 
and some additional power. 

Now, given an ISA board implementing all 3 capabilities, and the fact that 
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Pandora will have ISA slots, I don't think we need anything else. But we 
*do* need to get such a board designed and built! 

Agreed, and such a board would be equally usable in a PC environment 
as in pandora. If supporting PCs as development platforms becaomes a 
mainstream activity, we may also want to consider integrating the same 
(assumed FPGA) component as would be needed on the ISA card into a 
version of the Mnemo PCI card, this making a single card serve both purposes. 

David has an action to worry about this board along with the bringup crew. 

Quite aside from the question of using Pandora, I'd like a clarification on 
Tim's statement: " [ the Cerberus address ] in the Hestia to be non-zero 
(we have pin on the expansion connector to force that)". I thought that at 
least on the current Hestia PCB this was accomplished with a jumper inside 
the box, not with a pin accessable to the outside; Which is it? 

It's a pin on the expansion connector. When not driven there is a 
resisto inside the box which defines the level (0). When driven to 1 
on the connector the Euterpe address becomes 8. 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, February 22, 1995 9:03 PM 

'gmo' 

'pandora@news' 


Guillermo A. Loyola wrote (on Tue Feb 21) : 


I think we are mixing several different discussions here which don't necessaraly 
belong together. 

First question is how to connect a ROM to Cerberus, which in an implementation 
of Terpsichore without an onboard ROM interface is of paramount importance; 
in an MPP application is quite important so you can share the ROM; but for 
Euterpe in Hestia or Pandora is a lot less interesting. 

The more interesting question is How do we debug a Hestia- like box using 
Pandora? I would say that the minimum requirements are 1 . To be able to reset 
Hestia *without* having to reset Pandora at the same time, and 2. To be able 
to read and write Cerberus registers in Hestia ' s devices from Pandora. 
Although 

not a "minimum" requirement, we have been assuming that we will have {at least 
in the pre-Pandora cross -development environment) 3. A promiscous-master- slave 
interface that allows us to snoop on all Cerberus transactions and also to 
respond to any unused Cerberus address. 

A direct connection between Pandora's Cerberus bus and Hestia' s Cerberus bus 
allows us to do #2 above, but not #1 and certanly not #3; so it is only 
mildly instersting. 

I disagree on this one, and Craig has already pointed out that the provision of both logic 
clear and circuit reset bits in octlet 6 of all Cerberus devices is designed to allow any 
set of devices to be reset independent of any others . It should therefore be quite 
possible to reset Hestia independent of Pandora in a single Cerberus configuration. 

What Dave had talked about a couple of weeks ago sounded to me like a plan 
to implement an interface that would give us all 3 directly in Mnemo, which 
is fine by me, but only if it is easy to do with a minumal impact on Mnemo 's 
schedule; and it certanly does not require Mnemo to have a ROM interface. 

Since then, Craig pointed out that besides being able to read and write the Hestia 
registers from pandora, the main function we would want is to be able to emulate the boot 
rom. Now, while we can't access the whole Pandora boot rom via the Cerberus space 
(because the Cerberus address space of a single device is limited to 16 bits) we can get 
to a large chunk of it, presumably enough to be able to emulate the Hestia boot. We have 
not gone back to add a full master interface on Mnemo. That would add considerable 
complexity, and area and some additional power. 

Now, given an ISA board implementing all 3 capabilities, and the fact that 
Pandora will have ISA slots, I don't think we need anything else. But we 
*do* need to get such a board designed and built! 

Agreed, and such a board would be equally usable in a PC environment as in pandora. If 
supporting PCs as development platforms becaomes a mainstream activity, we may also want 
to consider integrating the same {assumed FPGA) component as would be needed on the ISA 
card into a version of the Mnemo PCI card, this making a single card serve both purposes. 

David has an action to worry about this board along with the bringup crew. 

Quite aside from the question of using Pandora, I'd like a clarification on 
Tim's statement: " [ the Cerberus address ] in the Hestia to be non-zero 
(we have pin on the expansion connector to force that)". I thought that at 
least on the current Hestia PCB this was accomplished with a jumper inside 
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the box, not with a pin accessable to the outside; Which is it? 

It's a pin on the expansion connector. When not driven there is a resisto inside the box 
which defines the level (0) . When driven to 1 on the connector the Euterpe address 
becomes 8 . 
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Subject: 


From: 


Sent: 

To: 

Cc: 


tbr (Tim B. Robinson) 

Wednesday, February 22, 1995 10:01 PM 

'graham' 

'geerf; 'rich' 

Mnemo PLL 


We overlooked a requirement for the Mnemo PLL, dictated by the need to be able to run 
Mnemo at minimum power setting (and hence at slow clock 

speeds) when operating as a PCI bridge. We need this mode to allow us to be able to build 
a PC add in card to connect to a Hermes channel where the power dissipation possible in 
the PC will be limited. 

I have been discussing this with rich, and he thinks it's fairly straight forward to 
correct (though will take about a week of work) with changes in just the SOFA logic 
associated with the PLL. By adding an optional divide be 2 stage in the loop we expect to 
be able to run the SOFA clock down to 324 MHz {which the Hermes channel at 
162MHz ) which corresponds to the minimum rate at which we can run the channel on Euterpe. 

Let me know if scheduling in this extra work is a problem. Sorry for the oversight. 


Tim 
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From: dickson (Richard Dickson) 

Sent: Thursday, February 23, 1995 12:57 AM 

To: 'tbr' 

Subject: cc 

tim, 

theres the /u/chip/euterpe/verilog/bsrc/cc/gards/makerrs 

how's about i 'date > clean-request' and cvs ci it. 
then fire off a new releasebom. i fear that the dff file is bad 
with all this starting and stopping, i always start a job from 
a clean state because it always raised the probability of the 
job finishing properly. 

dickson 
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From: tbr 

Sent: Thursday, February 23, 1995 1:00 AM 

To: 'dickson (Richard Dickson)' 

Subject: cc 
Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Wed Feb 22): 
tim, 

theres the /u/chip/euterpe/verilog/bsrc/cc/gards/makerrs 

how's about i 'date > clean -request' and cvs ci it 
then fire off a new releasebom. i fear that the dff file is bad 
with all this starting and stopping, i always start a job from 
a clean state because it always raised the probability of the 
job finishing properly. 

Yes, there is a corrupt .dff ftle. I suggest a clean start. 
The best way to update the clean-request is to do 

gmake forceclean 

which actually just appends the date (so there is a record of all the 
clean builds). The check it in and release again. (This time you 
should not need the -F becaus a file will have changed.) 

Tim 
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From: dickson (Richard Dickson) 

Sent: Thursday, February 23, 1995 1:11 AM 

To: 'tor' 

Subject: cc stumped 

tim, 

ok i did the cvs ci of a new clean-request file followed 
by a releasebom and i appears to fail just as the -F run previously, 
i'm puzzled about the page i got look at this ... 

Date: Wed, 22 Feb 1995 23:06:21 -0800 
From: chip@rhea (Buffalo Chip) 

Message-Id: <1 99502230706.XAA 101 59@rhea.microunity.com> 
Subject: pager log message 
X-sent-by: pager daemon 
Apparently-To: <dickson@rhea> 
Status: R 

page from chip to dickson: 

Release euterpe/verilog/bsrc/cc BOM 66.0 initiated by dickson completed @ Wed Fe 
b 22 23:05 : 1 8 PST 1 995 with exit status 0.. chip 


at face value it looks as though it successfully finished but in 
makerrs it failed the gards directories weren't deleted as a 
result of clean-request check in ??? 

dickson 
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From: Kleanthes Koniaris [kgk@hades] 

Sent: Thursday, February 23, 1995 2:01 AM 

To: 'geertcghades* 

Subject: A dumb question? 


Dear Geert : 

I am playing in the directory /u/chip/euterpe/verilog/bsrc/mst/ . 

I am looking at the file mst.v. For example, please consider the 
line : 


ff_l inOl (phi_a2p, phi_b2p, ESmusigna, ESmusigna_n, emus igna, emus igna_n) ; 

This means (if I understand) that symbol inOl is an instance of a Verilog module of 
"type" ff_l, and that inOl is made connected to the ten argumets provided inside the 
argument list. 


To see how many modules exist, I said 


egrep module *.v 


but only came up with the following list: 

- module msaccie is defined in file "msaccl6.v" 

- module msadf32 is defined in file "msadf32.v" 

- module msbooth is defined in file "msbooth.v" 

- module mscsaddl6a is defined in file "mscsaddl6a . v" 

- module mscsaddl6b is defined in file "mscsaddieb . v" 

- module mscsaddlSe is defined in file "mscsaddl6e . v" 

- module mshotc is defined in file "mshotc.v M 

- module mshotca is defined in file "mshotca.v" 

- module msinl6a is defined in file "msinl6a.v l, 

- module msinl6b is defined in file M msinl6b.v" 

- module msrcdl6 is defined in file "msrcdl6.v" 

- module msrcdlSa is defined in file "msrcdl6a.v" 

- module msrcdl6b is defined in file "msrcdl6b.v" 

- module mst is defined in file "mst.v" 

So, where is module ff_l defined? I looked inside the Makefile and still couldn't figure 
it out. (I assumed that the ff_l module isn't a Verilog "builtin, " but I forgot my 
Verilog text at work and cannot check right now. ) 


Kleanthes 


Kleanthes Koniaris, MicroUnity Systems Engineering, 2 55 Caspian Drive, Sunnyvale, CA, 
94089-1015. Work: 408-734-8100, FAX : 408-734-8136. 
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From: solo (John Campbell) 

Sent: Thursday, February 23, 1995 9:34 AM 

To: 'sysadmin' 

Cc: 'tau'; 'lisar (Lisa Robinson)'; 'doi (Derek Iverson)' 
Subject: cvs unmounted?? 

i don't know enough about automounter to tell you what is wrong, it 
just is. 

,...solo@echidna /u/chip/euterpe/proteus/compass/layouts 88 % cvs status bellybutt.Iy 
cvs status: in directory .: 

cvs [status aborted]: there is no repository /p/cvsroot/proteus/compass/layouts 
solo@echidna /u/chip/euterpe/proteus/compass/layouts 89 % 

solo@echidna /u/chip/euterpe/proteus/compass/layouts 95 % II /p/cvsroot/proteus 
lrwxrwxrwx 1 torn 29 Feb 10 04:52 /p/cvsroot/proteus -> /n/auspex/s48/cvsroot/proteus 

solo@echidna /u/chip/euterpe/proteus/compass/Iayouts 96 % Is /n/auspex/s48/cvsroot/proteus 
/n/auspex/s48/cvsroot/proteus not found 

solo@echidna /u/chip/euterpe/proteus/compass/layouts 97 % cd /n/auspex/s48/cvsroot/proteus 
/n/auspex/s48/cvsroot/proteus: No such file or directory. 
solo@echidna /u/chip/euterpe/proteus/compass/layouts 98 % 

regards, 

solo a.k.a. John Campbell x516 
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Subject: 


Sent: 
To: 

Cc: 


From: 


wayne (Wayne Freitas) 

Thursday, February 23, 1995 10:59 AM 

'rich'; 'dane'; 'yves'; 'noel'; 'arya'; 'rmm'; 'graham'; 'thuydo' 

'hestia' 

Re: Hestia power supply noise 


This is the outcome from the 2:30pm meeting. 

Attendees: Graham, Rich, Yves, Dane, Arya, Rick, Noel, Thuydo 

Currently RO specs the P-P noise as: 
3.3V lOOmV @<10MHz 
5.0V 50mV @< 10MHz 
12.0V 120mV @<10MHz 

Power supply ripple requirements were then defined as: 
Euterpe: 

PLL , <10mV between 1 and 20 MHz. This input is isolated from 
the 3.3V plane by a ferrite or inductor. Rich is to look into 
making sure this is an inductor. 

Digital, because there are some analog features tied through to 
digital plane (knobs, etc) the designs want ~10mV from ~60Hz to 
5 00MHz. 
Calliope : 

Same as above. 


<10mV from ~60Hz to 500MHz 

+12V: 

Rich calculated that he needed ~200uV P-P @ 400KHz for the 
external VCO 1 s . I didn't record the formula that he wrote to 
come to this conclusion, but as the frequency increased the P-P 
requirements loosened (Rich if you could provide your formula it 
might help) . It was concluded that a lOmV P-P would be defined, 
and a special filter needs to be designed for the VCO circuit. 

We also discussed some other problem encountered while testing the 
RO Module . 

Power : 

RO specs 40A +3 . 3V, 3A +5V, and 3A +12V. We currently 
calculate a requirement > 45A. for the 3.3V but only . 5A for +5V 
and .3A for +12V ( + fan requirements). Thuydo to contact RO to 
see if we can, and how reliablity is effected if we run more 
current on 3.3V but still stayed under 185W. 

Overshoot & OV protection: 

RO confirmed overshoot and is currently working on lOea modules. 
Overvoltage to be specified at 120% max. 

Isolation: 

Initial tests indicate a isolation problem between the 3 . 3V and 5V 
power. Will conduct additional tests to verify data, and provide 
RO to see if additional shielding can be added on module . 


+5V: 
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Subject: 


Sent: 
To: 

Cc: 


From: 


graham (Graham Y. Mostyn) 
Thursday, February 23, 1995 12:11 PM 
•tor' 

'geert'; 'rich'; 'graham' 
Re: Mnemo PLL 


Clearly we should make the change now to Mnemo. 

The other work impacted is the VCO supply filtering on Hestia, and the low-power 
synthesizer design for a future portable product; however, the delay in the first of these 
two does not - fortunately - affect the scheduled board respin. 

Graham . 

> From tbr Wed Feb 22 20:00:48 1995 

> Date: Wed, 22 Feb 1995 20:00:47 -0800 

> From: tbr (Tim B. Robinson) 

> To : graham 

> Subject: Mnemo PLL 

> Cc: geert, rich 

> Content -Length: 864 
> 

> We overlooked a requirement for the Mnemo PLL, dictated by the need to 

> be able to run Mnemo at minimum power setting (and hence at slow clock 

> speeds) when operating as a PCI bridge. We need this mode to allow us 

> to be able to build a PC add in card to connect to a Hermes channel 

> where the power dissipation possible in the PC will be limited. 
> 

> I have been discussing this with rich, and he thinks it's fairly 

> straight forward to correct (though will take about a week of work) 

> with changes in just the SOFA logic associated with the PLL. By 

> adding an optional divide be 2 stage in the loop we expect to be able 

> to run the SOFA clock down to 3 24 MHz (which the Hermes channel at 

> 162MHz ) which corresponds to the minimum rate at which we can run the 

> channel on Euterpe. 
> 

> Let me know if scheduling in this extra work is a problem. Sorry for 

> the oversight. 


> 


> Tim 


> 


> 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Thursday, February 23, 1995 1:24 PM 
'geeif 

rich_euterpe 


geert , 


i still have too many horizontal wires across sr. 
it looks as tho i can relieve it by readjusting columns of flops and muxes within sr. 
buses from nb were connecting to gates on the right hand side of layout instead of at the 
left side, there seems to be alot of these kinds of things, 
i 1 11 check in significant placement changes as i come up with them. 


dickson 
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From: 


tbr 


Sent: 

To: 

Cc: 


Thursday, February 23, 1995 3:26 PM 
'gmo' 

'pandora@news' 


Follow Up Flag: Follow up 
Flag Status: Red 

Guillermo A. Loyola wrote (on Thu Feb 23): 

In article <199502230302.TAA05721@aphrodite.microunity.com>, tbr@news (Tim B. Robinson) writes: 

|> I disagree on this one, and Craig has already pointed out that the 

|> provision of both logic clear and circuit reset bits in octlet 6 of 

|> all Cerberus devices is designed to allow any set of devices to be 

|> reset independent of any others. It should therefore be quite 

|> possible to reset Hestia independent of Pandora in a single Cerberus 

|> configuration. 

Yea, I keep forgetting that; sorry. In my defense (and I know it's splitting 
hairs) you can reset individual chips within Hestia, but you cannot cause 
a "whole box reset" like you could by grounding the Cerberus SD line. 

Agreed, but it is a reasonable assumption, that on leaving reset, the 
Euterpe in Hestia would be responsible for re-initializing the 
Calliope. So it ought to be possible to reset the box bu only 
resetting the Euterpe directly. 


Tim 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, February 23, 1995 3:27 PM 

'gmo' 

'pandora@news' 


Guillermo A. Loyola wrote (on Thu Feb 23) : 

In article <199502230302.TAA05721@aphrodite.microunity.com>, tbr@news (Tim B. Robinson) 
writes : 

> I disagree on this one, and Craig has already pointed out that the 

> provision of both logic clear and circuit reset bits in octlet 6 of 

> all Cerberus devices is designed to allow any set of devices to be 

> reset independent of any others. It should therefore be quite 

> possible to reset Hestia independent of Pandora in a single Cerberus 

> configuration. 

Yea, I keep forgetting that; sorry. In my defense (and I know it's splitting 
hairs) you can reset individual chips within Hestia, but you cannot cause 
a "whole box reset" like you could by grounding the Cerberus SD line. 

Agreed, but it is a reasonable assumption, that on leaving reset, the Euterpe in Hestia 
would be responsible for re- initializing the Calliope. So it ought to be possible to 
reset the box bu only resetting the Euterpe directly. 


Tim 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Thursday, February 23, 1995 10:33 PM 
'geert'; 'torn' 
'hopper'; 'ericm* 
random failure 


Follow Up Flag: Follow up 
Flag Status: Red 

Here's a good one; gmake being unable to invoke itself recursively: 

gmake -C /n/auspex/s23/euterpe-proteus-cp/leafgen /n/auspex/s23/euterpe-proteus~cp/leafgen/spice/leaf- 
wire/xbbufdh2s.sp /n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf-wire/xbor 1 6dh2s.sp /n/auspex/s23/euterpe-proteus- 
cp/leafgen/spice/leaf-wire/xbor 1 2dh2s.sp /n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf- 

wire/xbor6dh2s.sp /n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf-wire/xbor2dh2s.sp /n/auspex/s23/euterpe-proteus- 
cp/Ieafgen/spice/leaf-wire/xbbufdh 8 s. sp /n/auspex/s23/euterpe-proteus-cp/leafgen/sp ice/leaf-wire/xbbufdf8s.sp 
gmake[5]: Entering directory '/N/auspex/root/s23/euterpe-proteus-cp/leafgen' 
gmake[5]: gmake: Command not found 
gmake[5]: *** [do-make-leamet] Error 127 

gmake [5]: Leaving directory '/N/auspex/root/s23/euterpe-proteus-cp/Ieafgen r 

gmake[4]: *** [/n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf-wire/xbbufdh2s.sp] Error 1 

gmake[4]: Leaving directory "/N/auspex/roo^S/euterpe-proteus-cp/spice/misc' 

gmake[3j: *** [/n/auspex/s23/euterpe-proteus-cp/spice/misc/fix_tt.sed] Error 1 

gmake[3]: Leaving directory '/N/auspex/roo^^/euterpe-proteus-cp/leafgen' 

gmake[2]: *** [/n/auspex/s23/euterpe-proteus-cp/leafgen/time/xbffdh3s.tim] Error 1 

gmake [2]: Leaving directory '/N/auspex/root/s23/euterpe-proteus-cp/ged/ea' 

gmake[l]: *** [default] Error 1 

gmakefl]: Leaving directory '/N/auspex/root/s23/euterpe-proteus-cp/ged' 
gmake; *** [proteusmake] Error 1 


Now to be fair, I think this was probably a victim of the auspex 
reboot because the logfile was last touched at about that time: 

tbr@nosferatu /n/auspex/s41/euterpe-snapshot/euterpe/proteus 409 % Is -Is !$ 
Is -Is makerrs 

91 -rw-r-r~ 1 chip 92884 Feb 23 18:58 makerrs 
I have restarted the build. 

eric, was it down long enough for the automounter to have unmounted 
things out from under it? I was assuming it would have just hung 
around waiting. 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, February 23, 1995 10:33 PM 

'geert'; 'torn' 

'hopper'; 'ericm' 

random failure 


Here's a good one; gmake being unable to invoke itself recursively: 
gmake -C /n/auspex/s2 3/euterpe-proteus-cp/leafgen 

/n/auspex/s23 /euterpe-proteus- cp/leaf gen/ spice/ leaf -wire/xbbuf dh2s . sp 
/n/auspex/s23 /euterpe-proteus- cp/leaf gen/spice/leaf -wire/xborl6dh2s . sp 
/n/auspex/s23 /euterpe-proteus-cp/leaf gen/ spice/leaf - wire/xborl2dh2s . sp 
/n/auspex/ s23 /euterpe-proteus- cp/leaf gen/spice/leaf -wire/xbor6dh2s . sp 
/n/auspex/s23 /euterpe-proteus- cp/leaf gen/spice/leaf -wire/xbor2dh2s . sp 
/n/auspex/s23/euterpe-proteus- cp/leaf gen/spice/leaf -wire/xbbuf dh8s . sp 
/n/auspex/s23 /euterpe-proteus- cp/leaf gen/spice/leaf -wire/xbbuf df 8s . sp 
gmake [5] : Entering directory 

* /N/ auspex/root /s23 /euterpe-proteus - cp/leaf gen 1 
gmake [5]: gmake: Command not found 
gmake [5]: *** [do-make- leaf net] Error 127 
gmake [5]: Leaving directory 

*" /N/auspex/ root /s23 /euterpe-proteus -cp/leaf gen' 
gmake [4] : *** 

[/n/auspex/s23/euterpe-proteus-cp/leaf gen/ spice/leaf -wire/xbbuf dh2s . sp] 
Error 1 

gmake [4]: Leaving directory 

* /N/auspex/root/s23/euterpe-proteus-cp/spice/misc 1 

gmake [3] : *** [ /n/ auspex/ s2 3 / euterpe - p ro teus - cp/spice/misc/f ix_tt . sed] 
Error 1 

gmake [3]: Leaving directory 

"/N/auspex/ root /s2 3 /euterpe-proteus- cp/leaf gen' 

gmake [2] : *** [/n/auspex/s23/euterpe-proteus- cp/leaf gen/time/xbf f dh3s . tim] 
Error 1 

gmake [2]: Leaving directory VN/auspex/root/s23/euterpe-proteus-cp/ged/ea ' 
gmake [1]: *** [default] Error 1 

gmake [1] : Leaving directory VN/auspex/root/s23/euterpe-proteus-cp/ged ' 
gmake: *** [proteusmake] Error 1 


Now to be fair, I think this was probably a victim of the auspex reboot because the 
logfile was last touched at about that time: 

tbrOnosf eratu /n/auspex/s41/euterpe- snapshot /euterpe/proteus 4 09 % Is -Is !$ Is -Is 
makerrs 

91 -rw-r--r-- 1 chip 92884 Feb 23 18:58 makerrs 

I have restarted the build. 

eric, was it down long enough for the automounter to have unmounted things out from under 
it? I was assuming it would have just hung around waiting. 


Tim 
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From: tbr 

Sent: Friday, February 24, 1995 12:34 AM 

To: 'Frank Paturzo' 

Subject: Re: more trouble 

Follow Up Flag: Follow up 
Flag Status: Red 


Frank Paturzo wrote (on Thu Feb 23): 
>Are you confusing the machines? 

Yes, I screwed up. 

> 

>staypuft:/s3 

> 

>nosferatu:/s4 
>nosferatu:/s5 
>nosferatu:/s6 
>nosferatu:/s7 

> 

>/s3 is already in the list on nosferatu, but not on staypuft. s4..s7 
>are not on the list on nosferatu, but are mounted OK. 

> 

>Tim 

But, on staypuft, df gives me: 


Filesystem kbytes used avail capacity Mounted on 

/dev/sdOa 97455 9493 78217 11% / 

/dev/sdOg 236367 101718 111013 48% /usr 

/dev/sd5g 1952573 980679 776637 56% /si 

/dev/sd6g 1952573 1112345 644971 63% /s2 

/dev/sd7g 1952573 1113757 643559 63% /s3 


And staypuft's exports file on staypuft does have /s3 in the list. I 
re-exported the list. Please try now. 

Still can't see it on aphrodite: 


tbr@aphrodite ~ 406 % Is /n/staypuft/s* 
/n/staypuft/sl: 

age gmo lost+found 

dickson hopper 

/n/staypuft/s2: 

age lost+found 

Nosferatu should work ok now too. 

Again, aphrodite only sees si, s2, and s3: 
tbr@aphrodite ~ 407 % Is /n/nosferatu/s* 
/n/nosferatu/sl: 

lost+found stb technology 
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proteus.tbr stb.doi tools 
euterpe proteus.uchip stb.jeffm verify 


/n/nosferatu/s2: 

euterpe proteus proteus.tbr tools 
lost+found proteus. local technology 

/n/nosferatu/s3: 

CVS orchis proteus. lisar 

lost+found proteus 
tbr@aphrodite ~ 408 % Is /n/nosferatu/s5 
/n/nosferatu/s5 not found 
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To: 


Subject: 


From: 
Sent: 


tbr 

Friday, February 24, 1995 12:49 AM 
'Frank Paturzo' 
Re: Got one! 


Follow Up Flag: Follow up 
Flag Status: Red 

Frank Paturzo wrote (on Thu Feb 23): 
Maybe, but you know how to fix it! B A ) 
Looks like s6 & s7 are there too. 

Well, it is working now, but I did nothing to cause it: 


tbr@aphrodite ~ 409 % Ms 
Is /n/nosferatu/s5 
/n/nosferatu/s5 not found 

tbr@aphrodite -410% /usr/Iocal/etc/amq -u -f /n/nosferatu 
tbr@aphrodite ~ 41 1 % !ls 
Is /n/nosferatu/s5 

Is: /n/nosferatu/s5: Stale NFS file handle 
tbr@aphrodite -412%!! 
Is /n/nosferatu/s5 


proteus.tbr stb.doi tools 
euterpe proteus.uchip stbjeffm verify 
tbr@aphrodite - 415 % Is /n/nosferatu/s5 

euterpe lost+found 


tbr@aphrodite ~ 4 1 3 % ! 
!: Command not found. 
tbr@aphrodite - 414 % Is /n/nosferatu/sl 


euterpe lost+found 


lost+found stb technology 
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From: 


tbr 


Sent: 


Friday, February 24, 1995 1:47 AM 

'geert' 

'sysadmin' 

snapshot rebuild 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Sorry about the page, it is a false alarm. It failed again, with the 
same type of error I got earlier in the evening: 

gmake -C /n/auspex/s23/euterpe-proteus-cp/leafgen /n/auspex/s23/enterpe-proteus-cp/leafgen/spice/leaf- 
wire/xbbufdh2s.sp /n/auspex/s^S/euterpe-proteus-cp/leafgen/spice/leaf-wire/xbor 1 6dh2s.sp /n/auspex/s23/euterpe-proteus- 
cp/leafgen/spice/leaf-wire/xbor 1 2dh2s.sp /n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf- 

wire/xbor6dh2s .sp /n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf-w ire/xbor2dh2s .sp /n/auspex/s2 3 /euterpe-proteus- 
cp/leafgen/ spice/leaf-wire/xbbufdh 8s .sp /n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf-wire/xbbufdf8s . sp 
gmake [5]: Entering directory '/N/auspex/root/s23/euterpe-proteus-cp/leafgen' 
gmake[5]: gmake: Command not found 
gmake [5]: *** [do-make-leamet] Error 127 

gmake[5]: Leaving directory '/N/auspex/root^S/euterpe-proteus-cp/leafgen' 

gmake[4]: *** [/n/auspex/s23/euterpe-proteus-cp/leafgen/spice/leaf-wire/xbbufdh2s.sp] Error 1 

gmake[4]: Leaving directory , / r N/auspex/root/s23/euterpe-proteus-cp/spice/misc' 

gmake[3]: *** [/n/auspex/s23/euterpe-proteus-cp/spice/misc/fix_tt,sed] Error 1 

gmake[3]: Leaving directory '/N/auspex/roo^^/euterpe-proteus-cp/leafgen' 

gmake[2]: *** [/n/auspex/s23/euterpe-proteus-cp/leafgen/time/xbffdh3s.tim] Error 1 

gmake[2]: Leaving directory '/N/auspex/root/s23/euterpe-proteus-cp/ged/ea' 

gmakef 1 ] : * * * [default] Error 1 

gmake[l]: Leaving directory , /N/auspex/root/s23/euterpe-proteus-cp/ged' 
gmake: *** [proteusmake] Error I 


This time I can't blame it on the auspex reboot. 
1 have restarted it and hopefully it will get further. 


Tim 
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From: lisar (Lisa Robinson) 

Sent; Friday, February 24, 1995 10:29 AM 

To: 'woody' 

Cc: *billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr' 
Subject: brmiss.. 

Again both tests are in the fail loop. I have run these test so many times 

now in verilog with different timing and cannot reproduce the problem, I think that 

we need to debug on the h/w simulator at least to the point that we understand 

why there is a difference between the verilog and the 2 h/w simulators. 

Of course one difference that springs to mind is the gtlb and cr models. I will 

start up a run in verilog using these - just in case. 

Lisa R. 

PS the traces are on rhodan /s3/euterpe/verilog/bsrc/res/24295. 3 761 /results 
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From: pmayer (Patricia Mayer) 

Sent: Friday, February 24, 1995 11:39 AM 

To: 'dbulfer 1 

Cc: 'tbr'; 'pmayer' 

Subject: Pandora-Euterpe 

Are you ready? 

Howard will be wrapping up the Band Split Filter 
early next week. The next board on the list is 
Pandora-Euterpe . . ? 

So whats the your status? 

Thanks 
-Pattie 
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To: 


Sent: 


From: 


wingard (Drew Wingard) 

Friday, February 24, 1995 12:46 PM 

'sysadmin' 


Subject: Need old files from backup tape 

I need to resurrect an old program. I saved the code, but managed to delete 
the configuration files and examples. 

Can you please install: 

/n/auspex/s24/wrngard/chip/calliope/verilog/src 
and 

/n/auspex/s24/wingard/ch ip/euterpe/veri Iog/bsrc 
someplace where I can access them? 

My recollection is that they occupy approx 300 MBytes (which is why they 
were deleted...). 

None of the files that 1 care about were modified after May 26th last year. 

Best Regards, 
Drew 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr 

Friday, February 24, 1995 2:08 PM 
'dbulfer (David Buffer)' 
'gmo (Guillermo A. Loyola)'; 'mnemo' 
PCI Event Number Register 


Follow Up Flag: Follow up 
Flag Status: Red 


David Bulfer wrote (on Fri Feb 24): 

The PCI Event Number Register is used to specify the bits set in the 
Event Register by the various sources of events. Any thought to the 
power-up/reset value? I would guess "0" is OK. 

To the extent that no event can be reported till the processor issues 
the blocking read to the event register address, I don't think it's an 
issue. However, bit 0 is reserved in Euterpe as the bit on which 
timer interrupts get reported, so we are unlikely to ever want to 
program a 0 here. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, February 24, 1995 2:08 PM 

'dbulfer (David Bulfer)' 

'gmo (Guillermo A. Loyola)'; 'mnemo' 

PCI Event Number Register 


David Bulfer wrote (on Fri Feb 24) : 

The PCI Event Number Register is used to specify the bits set in the 
Event Register by the various sources of events. Any thought to the 
power-up /reset value? I would guess "0" is OK. 

To the extent that no event can be reported till the processor issues the blocking read to 
the event register address, I don't think it's an issue. However, bit 0 is reserved in 
Euterpe as the bit on which timer interrupts get reported, so we are unlikely to ever want 
to program a 0 here. 


Tim 
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From: 


tbr 


To: 


Subject- 


Sent: 


Cc: 


Friday, February 24, 1995 3:26 PM 
'pmayer (Patricia Mayer)' 
'dbulfer'; 'woody'; 'pmayer' 
Pandora-Euterpe 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Fri Feb 24): 
Are you ready? 

Howard will be wrapping up the Band Split Filter 
early next week. The next board on the list is 
Pandora-Euterpe . . ? 

So whats the your status? 

Now we understand the flow we need a schematic. Jay has a netlist 
and should be working on getting a matching schematic representation. 


Tim 
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From: ken (Ken Hsieh) 

Sent: Friday, February 24, 1995 5:40 PM 

To: 'wingard' 

Cc: 'sysadrrv* 

Subject: Re: Need old files from backup tape 
Files have been restored. /Wauspex/s29/wingard_restore 


Ken 


> From wingard Fri Feb 24 10:45:53 1995 

> Date: Fri, 24 Feb 1995 10:45:51 -0800 

> From: wingard (Drew Wingard) 

> To: sysadmin 

> Subject: Need old files from backup tape 

> Content-Length: 464 

> 

> I need to resurrect an old program. I saved the code, but managed to delete 

> the configuration files and examples. 

> 

> Can you please install: 

> /n/auspex/s24/wingard/chip/calliope/verilog/src 

> and 

> /n/auspex/s24/w ingard/ch ip/euterpe/veril og/bsrc 

> someplace where I can access them? 

> 

> My recollection is that they occupy approx 300 MBytes (which is why they 

> were deleted...). 

> 

> None of the files that I care about were modified after May 26th last year. 

> 

> Best Regards, 

> Drew 

> 
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From: woody (Jay Tomlinson) 

Sent: Friday, February 24, 1995 6:42 PM 

To: 'tor' 

Cc: 'hopper' 

Subject: tool for schematic from verilog? 
Tim, 

What is this tool that you guys used to use? I would like to use it on a shell 
of euterpe to give me a starting point for the euterpe module. I only expect to 
do this 1 or 2 times to get euterpe and mnemo transferred and then from there I 
plan to only edit the schematic. 

Jay 
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From: hopper (Mark Hofmann) 

Sent: Friday, February 24, 1995 8:12 PM 

To: 'Jay Tomlinson' 

Cc: 'tbr (Tim B. Robinson)'; 'vant'; 'albers (Daniel Albers)' 
Subject: Re: tool for schematic from verilog? 

Jay Tomlinson writes: 
Tim, 

What is this tool that you guys used to use? 
I would like to use it on a shell 

of euterpe to give me a starting point for the euterpe module. 
I only expect to 

do this 1 or 2 times to get euterpe and mnemo transferred and 

then from there I 

plan to only edit the schematic. 


Jay, 

For single block diagram type representations (one block per page) I 
think the tool you want is "shebody". Here is a clipping from "shebody -help": 

/u/chip/tools/bin/shebody creates a Valid GED/Concept 
compatible body by reading the user specified edif file. The 
output is placed in a directory 

whose name is created by extracting the root of the edif file name. 
If either the geddir or the cell directory do not exist, 
/u/chip/tools/bin/shebody will create them automatically. 

Within the geddir, /u/chip/tools/bin/shebody searches the 

Valid work file or libarary file for a match with the cell directory name. 

If a match is found 

no changes are made to the work/libarary file, otherwise an entry 
for this cell is added. If the work/library file does not exist, 
/u/chip/tools/bin/shebody createse that automatically as well. 

The default output name is body. 1. 1 and can be overwridden with the 
'-o new_file.name' switch. If a 'subckt' file is desired in the 
GED/Concept cell directory to stop the Valid compiler at that level, 
then the -s switch must be used. 

The user has the option to generate the spice cn. 1 file for the 
compiler. If you want this, please use the -p command line option. 

However, for the longer term the answer is probably to enter board level 
information in concept (the schematic editor) and use the tools we have 
to annotate the body with the proper attributes so that the netlist can 
be passed on through to the Packager and Allegro for layout. Perhaps 
Dan or another Concept user could help you out there. 

-hopper 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Friday, February 24, 1995 8:27 PM 

'geert (Geert Rosseel)' 

hcO 


hi Geert, 

I'm running hcO in my area 

~hopper/chip/euterpe/verilog/bsrc/hc/gards 

The output file is ~hopper/chip/euterpe/verilog/bsrc/hc/out 

So far it doesn't look good. It appears to be wider than the old hcO . 

I think we want the right edge to be <=5 60. 


-mark 
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Subject: 


Sent: 

To: 

Cc: 


From: 


woody (Jay Tomlinson) 

Saturday, February 25, 1995 1:01 AM 

'geerf 

'tbr'; 'hopper' 
uu placement 


geert , 


I checked in a placement of uu. Everything is placed, but pim2pif fails in 
pass2 with the following error: 

/n/auspex/s2 0/woody/chip/euterpe/tools/bin/pim2pif : Processing the gards/uu-pass2 .pirn 
file. . . 

@: Badly formed number. 
Any idea what this means? 


woody 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Saturday, February 25, 1995 2:51 AM 

'Jay Tomlinson' 

'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)' 
Re: uu placement 


Jay Tomlinson writes: 
geert, 

I checked in a placement of uu. Everything is placed, but pim2pif fails in 
pass2 with the following error: 

/n/auspex/s20/woody/chip/euterpe/tools/bin/pim2pif : Processing the gards/uu-pass2 .pirn 
file. . . 

@: Badly formed number. 

Any idea what this means? 

I'm looking into this. It probably means that one of the input files to pim2pif was 
somehow corrupted. 

Jay I also notice that you are using ■ .nopifpack" . I checked my code I don't appear to 
have fully implemented this. I will work on it. In the meantime you could set 

PIFPACK_SQUEEZE = -1 
PIFPACK_DISTANCE = -1 

in your local Makefile 

Or, just do _not_ create the file "usepifpack" in your local uu area. 
Either way, pifapcking should then be turned off. 


-hopper 
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From: hopper (Mark Hofmann) 

Sent: Saturday, February 25, 1 995 3:24 AM 

To: 'Jay Toml'inson 1 

Cc: 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)' 
Subject: Re: uu placement 

Jay Tomlinson writes: 
geert, 

I checked in a placement of uu. Everything is placed, but pim2pif fails in 
pass2 with the following error: 

/n/auspex/s20/woody/chip/euterpe/tools/bin/pim2pif: Processing the gards/uu-pass2.pim file... 
@: Badly formed number. 

Any idea what this means? 

I have some fixing to do. 

The quickest thing to get you going again is to remove the ".nopirpack" 
statement in you .pirn file. This seems to be what's causing the problem. 

I'm working on getting .nopirpack to function properly. 

thanks, 
-hopper 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 

Saturday, February 25, 1995 12:53 PM 

'geerf 

rich_euterpe 


geert, 


after playing around with the new coordinates you gave me yesterday i have a few 
questions . are we intentionally leaving 

6 rows free on the top of gt on purpose ? i'd sure like to move gt 6 rows higher and allow 
for more hight in the cc layout (its only 60 rows high with the new coordinates) i think 
thats why the confusion about whether i had taken 4 rows off of cc . 


dickson 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Saturday, February 25, 1995 12:57 PM 

Tim B. Robinson' 

■geert (Geert Rosseel)'; 'wampler (Kurt Wampler)' 
Re: pcomp core file 


Tim B. Robinson writes: 

Geert Rosseel wrote (on Sat Feb 25) : 

I have never had problems with that section. I have builda couple of chip_euterpe 
versions in the snapshot before for LVS/DRC and they all had ck in it. 

I'll try a different section. I am doing this in a completely clean 
checked out area, so it's possible there is something 
different /missing in a clean copy. 

I'll try ck from my local area and see if it works for me. 


- hopper 


Exhibit Cll 


Page 490 of 5 


From: hopper (Mark Hofmann) 

Sent: Saturday, February 25, 1 995 1 :02 PM 

To: 'tbr (Tim B. Robinson)' 

Cc: 'wampler (Kurt Wampler)'; 'geert (Geert Rosseel)' 

Subject: ck okay when I run 


Hi Tim, 

I'm pointing my proteus at /n/auspex/s23/euterpe-proteus-cp and running from the /u/chip 
euterpe. Pcomp on pass 1 seems to work okay: 
(I ran this on cyclops) 

-hopper 

cd gards; HOME=/n/auspex/s3 2/hopper/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/ s3 2 /hopper/chip/euterpe/ tools/ si/ license/license 
.dat DISPLAY=clio: 0. 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/s32/hopper/chip/euterpe 
/n/auspex/s32/hopper/chip/euterpe/tools/sl/bin/invoke pcomp ck-passl -listing ck- 
passl . pcomp . lis 

Requires a minimum license of gardsfel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS PCOMP 7.121 Physical Compiler 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: ck-passl Started at: 95/02/25 18:57:36 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: CK 
Processing Expansion level: SLNET 

... Start of netlist processing. 

. . . Circuit name : CK 

. . . Processing CDL. 

... CH I PNAME : SOFA ; 


Processing header of user PDL . 
PHYSICALLIB : PBUILD; 
Processing header of system PDL . 
PHYSICALLIB : PBUILD ; 
Processing rest of 
Processing rest of 
Processing TDL. 
TECHNOLOGYLIB : SOFA; 
Computed Grid_Size 
Final Processing. 

Successful physical compilation (with warnings) . 
»> Loading logical netlist. 

. . . Successful completion. GARDS design file created. 


user PDL. 
system PDL. 


1000 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/02/25 18:57:47 

0 Hrs 0 Mins 3 Sees 

0 Hrs 0 Mins 11 Sees 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Saturday, February 25, 1995 3:41 PM 

•geert (Geert Rosseel)' 

hcO 


hi geert, 


i have another run of hcO in progess. it's currently on the 5th iteration and it's 
looking better (xmax @ 542, it needs to be <= 560) . This is a completely pushed around 
placement, so it may not meeet internal or external timing, but it might fit physically, 
results are developing in the usual 
place : 

/u/hopper/chip/euterpe/verilog/bsrc/hc/gards 
the output file is : 

/u/hopper/chip/euterpe/verilog/bsrc/hc/out 


-mark 
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From: hopper (Mark Hofmann) 

Sent: Saturday, February 25, 1995 6:02 PM 

To: Kurt Wampler' 

Cc: 'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)' 
Subject: Re: GARDS problem 

Kurt Wampler writes: 

GARDS coredumps are inscrutable to me « the binaries are stripped, and 
without source code I can't get meaningful traceback information. 

However, I do see something corrupt in one of the source files being read 
by PCOMP. The file ck-passlmacros.pdl is missing its header lines, 
and is also missing the PDL code for cgclockbias, even though cgclockbias 
*is* required by the netlist 

Probing further, it appears that the build of clockbias in: 
/n/staypuft/s3/tbr/euterpe/clockbias 

did not complete correctly; the cgclockbias. pd! file in this area 
is zero-length, which explains the corruption of the ck-passlmacros.pdl 
file. Looking at timestamps on the files, it looks suspiciously like 
the clockbias make (or the machine on which it was running) may have 
crashed around 6:58PM on Feb 23 (the time stamp on cgclockbias. pdl) and 
then the job was restarted around 8:50PM that same night; seeing the 
empty (but up-to-date) cgclockbias.pdl, the make went on to build 
cgclockbias. edif etc. (Or maybe an auspex reboot or some other disturbance 
caused the problem.) 

Anyway, it might be best to blow away this clockbias directory and re-make 
it; there might be other problems with it besides the empty pdl file. 
(I just did a local make of cgclockbias.pdl to make sure it still builds 
properly; it was successful.) 

Great job of detection, Kurt! 

-hopper 
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From: hopper (Mark Hofmann) 

Sent: Saturday, February 25, 1995 6:16 PM 

To: 'Lisa Robinson' 

Cc: 'tbr (Tim B. Robinson)' 

Subject: Re: vxi on nosferatu 

Lisa Robinson writes: 

VXI 1.1 Sat Feb 25 22: 13:49 1995 

* Copyright Simulation Technologies Corporation 1992. * 

* All Rights Reserved. Licensed Software. * 
Error [-9]; feature "VXI-Base" 

invalid host 

gmake[l]: *** [,xp_dir/c_euterpe_wrap.edif2] Error 1 
gmake[l]: Leaving directory 7s2/euterpe/verilog/bsrc' 
gmake: *** [czycad] Error 1 
page queued 
starting paged 

Did this just start failing recently? 

I have no record of ever getting keys for hostid 0x723 5 fabb. We requested 
them last year. 

-hopper 
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From: 


tbr 


To: 


Sent: 


Subject; 


Cc: 


Saturday, February 25, 1995 8:20 PM 
"wai-ripler" 
'hopper 1 ; 'geert' 
GARDS problem 


Follow Up Flag: Follow up 
Flag Status: Red 

I just got a core file from pcomp: 

cd gards; HOME=/n/staypuft/s3/tbr/euterpe/tools LM_LICENSE_FILE=/n/staypuft/s3/tbr/euterpe/tools/sl/license/license.dat 
DISPL A Y= 1 92.2 1 6. 1 97 .49:0 .0 SL_TOTAL_DURATION=500 

CHIPROOT-/n/staypuft/s3/tbr/em^ pcomp ck-passl -listing ck- 

passl.pcomp.lis 

Requires a minimum license of gardsfe!_3 or gards 1_3 . 
Applicable licenses available at your installation : 

gardsconfig_3 
Checked out one user token of a gardsconfig_3 license. 

Arithmetic exception (core dumped) 

gmake[2]: *** [gards/ck-passl. pcomp. lis] Error 8 

gmake[2]: Leaving directory 7s3/tbr/euterpe/verilog/bsrc/ck' 

gmakefl]: *** [ck-base.netcap] Error 1 

gmakefl]: Leaving directory 7s3/tbr/euterpe/verilog/bsrc/ck' 

gmake: *** [ckgards] Error I 


The dump is in /n/staypuft/s3/tbr/euterpe/verilog/bsrc/ck/gards/core 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 25, 1995 8:20 PM 

'warn pier' 

'hopper'; 'geert' 

GARDS problem 


I just got a core file from pcomp: 

cd gards; HOME=/n/staypuft/s3/tbr/euterpe/ tools 

LM_LICENSE_PILE=/n/staypuf t/s3/tbr/euterpe/tools/sl/license/license.dat 

DISPLAY=192 .216. 197. 49:0.0 SL_TOTAL_DURATION=50 0 CHIPROOT=/n/staypuf t/s3 /tbr/euterpe 

/n/staypuf t/s3/tbr/euterpe/tools/sl/bin/ invoke pcomp ck-passl -listing ck-passl .pcomp . lis 

Requires a minimum license of gardsfel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

Arithmetic exception (core dumped) 

gmake [2] : *** [gards/ck-passl . pcomp . lis] Error 8 

gmake [2] : Leaving directory Vs3/tbr/euterpe/verilog/bsrc/ck' 

gmake [1] : *** [ck-base . netcap] Error 1 

gmake [1] : Leaving directory Vs3/tbr/euterpe/verilog/bsrc/ck' 
gmake: *** [ckgards] Error 1 


The dump is in /n/staypuf t/s3/tbr/euterpe/verilog/bsrc/ck/gards/core 


Tim 
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From: geert (Geert Rosseel) 

Sent: Saturday, February 25, 1995 8:44 PM 

To: 'tbr'; 'wampler' 

Cc: 'hopper' 

Subject: Re: pcomp core file 

I have never had problems with that section. I have builda couple of chip_euterpe 
versions in the snapshot before for LVS/DRC and they all had ck in it. 

Geert 
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From: 
Sent: 


tbr 


Saturday, February 25, 1995 8:46 PM 
'geert (Geert Rosseel)' 
'hopper'; 'wampler' 
Re: pcomp core file 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Feb 25): 

1 have never had problems with that section. I have builda couple of chip euterpe 
versions in the snapshot before for LVS/DRC and they all had ck in it. 

I'll try a different section. I am doing this in a completely clean 
checked out area, so it's possible there is something 
different/missing in a clean copy. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 25, 1995 8:46 PM 

'geert (Geert Rosseel)' 

'hopper'; 'warn pier' 

Re: pcomp core file 


Geert Rosseel wrote (on Sat Feb 25) : 

I have never had problems with that section. I have builda couple of chip_euterpe 
versions in the snapshot before for LVS/DRC and they all had ck in it. 

I'll try a different section. I am doing this in a completely clean checked out area, so 
it's possible there is something diff erent/missing ,in a clean copy. 


Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Saturday, February 25, 1995 1 1 :50 PM 
'hopper (Mark Hofmann)' 
•geert (Geert Rosseel)'; 'wampler (Kurt Wampler)' 
ck okay when I run 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofmann wrote (on Sat Feb 25): 


Hi Tim, 

I'm pointing my proteus at M/auspex/s23/euterpe-proteus-ep and running 
from the /u/chip euterpe. Pcomp on pass 1 seems to work okay: 
(I ran this on cyclops) 

I'm using the same proteus, but the problem is quite reproducible for 
me. Under the three on staypuft. However, in my other tree (under my 
home directory it works fine.) Im baffled, so I home the core file 
reveals a clue. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, February 25, 1995 11:50 PM 

'hopper (Mark Hofmann)' 

'geert (Geert Rosseel)'; 'wampler (Kurt Wampler)' 

ck okay when I run 


Mark Hofmann wrote (on Sat Feb 25) : 


Hi Tim, 

I'm pointing my proteus at /n/auspex/s23/euterpe-proteus-cp and running 
from the /u/chip euterpe. Pcomp on pass 1 seems to work okay: 
(I ran this on eye lops) 

I'm using the same proteus, but the problem is quite reproducible for me. Under the three 
on staypuft. However, in my other tree (under my home directory it works fine.) Im 
baffled, so I home the core file reveals a clue. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Sunday, February 26, 1995 12:16 AM 

To: 'hopper' 

Cc: W 

Subject: vxi on nosferatu 


VXI 1.1 Sat Feb 25 22:13:49 1995 

* Copyright Simulation Technologies Corporation 1992. * 

* All Rights Reserved. Licensed Software. * 
Error [-9]; feature "VXI-Base" 

invalid host 

gmake[l]: *** [.xp_dir/c_euterpe_wrap.edif2] Error 1 
gmake[l]: Leaving directory 7s2/euterpe/veriIog/bsrc' 
gmake: *** [czycadj Error 1 
page queued 
starting paged 
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Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Sunday, February 26, 1995 12:36 AM 

•tor' 


Subject: 


'geerf; 'hopper 1 

Re: GARDS problem 


tbr writes: 


>I just got a core file from pcomp: 
[ snip ] 

GARDS coredumps are inscrutable to me -- the binaries are stripped, and 
without source code I can't get meaningful traceback information. 

However, I do see something corrupt in one of the source files being read 
by PCOMP. The file ck-passlmacros .pdl is missing its header lines, 
and is also missing the PDL code for cgclockbias, even though cgclockbias 
*is* required by the netlist. 

Probing further, it appears that the build of clockbias in: 

/n/staypuf t/s3/tbr/euterpe/clockbias 

did not complete correctly; the cgclockbias .pdl file in this area 
is zero-length, which explains the corruption of the ck-passlmacros .pdl 
file. Looking at timestamps on the files, it looks suspiciously like 
the clockbias make (or the machine on which it was running) may have 
crashed around 6:58PM on Feb 23 (the time stamp on cgclockbias .pdl) and 
then the job was restarted around 8:50PM that same night; seeing the 
empty (but up-to-date) cgclockbias .pdl, the make went on to build 
cgclockbias . edif etc. (Or maybe an auspex reboot or some other disturbance 
caused the problem.) 

Anyway, it might be best to blow away this clockbias directory and re -make 
it; there might be other problems with it besides the empty pdl file. 
(I just did a local make of cgclockbias .pdl to make sure it still builds 
properly; it was successful.) 


- Kurt 
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From: 


tbr 


Sent: 


Sunday, February 26, 1995 12:47 AM 

•wampler (Kurt Wampler)' 

'geert'; 'hopper* 

Re: GARDS problem 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Sat Feb 25): 
tbr writes: 


>I just got a core file from pcomp: 
[ snip ] 

GARDS coredumps are inscrutable to me - the binaries are stripped, and 
without source code I can't get meaningful traceback information. 

However, I do see something corrupt in one of the source files being read 
by PCOMP. The file ck-passlmacros.pdl is missing its header lines, 
and is also missing the PDL code for cgclockbias, even though cgclockbias 
*is* required by the netlist. 

Probing further, it appears that the build of clockbias in: 

/n/staypuft/s3 /tbr/euterpe/cl ockbi as 

did not complete correctly; the cgclockbias.pdl file in this area 

is zero-length, which explains the corruption of the ck-passlmacros.pdl 

file. Looking at timestamps on the files, it looks suspiciously like 

the clockbias make (or the machine on which it was running) may have 

crashed around 6:58PM on Feb 23 (the time stamp on cgclockbias.pdl) and 

then the job was restarted around 8:50PM that same night; seeing the 

empty (but up-to-date) cgclockbias.pdl, the make went on to build 

cgclockbias.edif etc. (Or maybe an auspex reboot or some other disturbance 

caused the problem.) 

Aha! I think that's the time the auspex was shut down. 

Anyway, it might be best to blow away this clockbias directory and re-make 
it; there might be other problems with it besides the empty pdl file. 
(1 just did a local make of cgclockbias.pdl to make sure it still builds 
properly; it was successful.) 

Will do. Thanks for the detective work. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, February 26, 1995 12:47 AM 

'wampler (Kurt Wampler)' 

'geerf; 'hopper' 

Re: GARDS problem 


Kurt Wampler wrote (on Sat Feb 25) : 
tbr writes : 


>I just got a core file from pcomp: 
[ snip ] 

GARDS coredumps are inscrutable to me -- the binaries are stripped, and 
without source code I can't get meaningful traceback information. 

However, I do see something corrupt in one of the source files being read 
by PCOMP. The file ck-passlmacros .pdl is missing its header lines, 
and is also missing the PDL code for cgclockbias, even though cgclockbias 
*is* required by the netlist. 

Probing further, it appears that the build of clockbias in: 

/n/staypuf t/s3/tbr/euterpe/clockbias 

did not complete correctly; the cgclockbias .pdl file in this area 
is zero-length, which explains the corruption of the ck-passlmacros .pdl 
file. Looking at timestamps on the files, it looks suspiciously like 
the clockbias make {or the machine on which it was running) may have 
crashed around 6:58PM on Feb 23 (the time stamp on cgclockbias .pdl) and 
then the job was restarted around 8:50PM that same night; seeing the 
empty (but up-to-date) cgclockbias .pdl, the make went on to build 
cgclockbias .edif etc. (Or maybe an auspex reboot or some other disturbance 
caused the problem.) 

Aha ! I think that's the time the auspex was shut down. 

Anyway, it might be best to blow away this clockbias directory and re-make 
it; there might be other problems with it besides the empty pdl file. 
(I just did a local make of cgclockbias .pdl to make sure it still builds 
properly; it was successful.) 

Will do. Thanks for the detective work. 


Tim 
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Sent: 
To: 

Subject: 


From: 


tbr 

Sunday, February 26, 1995 11:31 AM 
'torn' 

staypuft:/s3 


Follow Up Flag: Follow up 
Flag Status: Red 


We seem to be thrashing for disk space in staypuft:/s3. 

I had built a new euterpe environment there after the new space came on line, 

so we had another place to run verilog simulations with huge dump 

files (-500MB), but the Creole stuff has stolen that (and I suspext a 

build I was doing last night which failed in topt would have been 

because of disk space, but I'm not certain because there is about 

130MB there now). 

How close is the Creole build to being done, and how much more space 
will you need? Currently we do have a lot of space on nosferatu. 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr 

Sunday, February 26, 1995 11:33 AM 
'torn' 

ged2lvs failure 


Follow Up Flag: Follow up 
Flag Status: Red 

Heres another thing that died: 

MicroUnity Spice Interface run on Feb 25 22:51 : 1 1995 
DESIGN NAME : 'EUTERPEPASS 1 1 
DESIGN COMPILATION ON Feb 25 22:51:4 1995 


3 errors detected 
1 oversights detected 
59 warnings detected 

cpu time 0:25:35 
elapsed time 2:11:34 

** ERROR** in <none>(): missing .end statement 
mv euterpe-passl.sp euterpe-passl. spivs 


I've not seen this one before. Could this be disk space too? 


Tim 
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To: 


Subject: 


From: 
Sent: 


tbr 

Sunday, February 26, 1995 11:38 AM 

'torn' 

ged2lvs 


Follow Up Flag: Follow up 
Flag Status: Red 


I found the following in the logfile, which looks bizzarre to me (I 
didn't see it on the xterm screen where the outputs was, but it was in 
the log file): 

(00:00:03.16) 

Calling ValidCompiler ... 

Reading logical database \n|n/D-D\a|n/n-n\a|n/n-n\n|n/n-D\n|n/n-D\D|D/D-D\a|D/ 

□\n|n/D-D\D|D/n-D\o|D/D-D\a|D/D-D\D|D/D-a\n|a/n-n\D|D/n-D\D|n/D-D\Dp/D-D\Q|D/a-n\a|D/D- 

□\a|D/n-n\D|Q/D-D\Djn/D-D\D|n/n-D\D|D/n-a\nja/n-n\niD/n-n\o|a/D-a\a|D/a-D\D|G/n-a\D|D/a- 

□\n|n/n-n\n|n/n-n\n|n/n-n\n|n/a-n\n|D/D-a\a|D/D-D\D|D/D-n\n|n/n-n\n|D/a-n\D|D/n-n\n|D/a- 

□\a|D/D-n\a|n/n-n\D|D/n^ 

□\nja/D-n\a|a/n-D\n|D/n-^ 

n\n|D/D-n\aia/a-a\D|D/D-D\D|a/D-D\D|n/n-n\a|D/D-D\a|D/D-D\DjD/G-D\n|a/n-a\n|n/n-D\n|a/n- 

□\n|n/n-n\D|D/n-n\njn/n-m 

□\D|n/n-a\D|D/D-n\aja/D-n\D|M 

□\njn/n-n\n|n/n-n\njn/n-n\^^ 

□\a|G/G-D\D|a/a-D\D|a/n-a\D|n/a-D\n|D/D-D\D|D/D-n\n|D/n-a\a|a/D-a\D|D/a-a\D|D/D-n\D|n/D- 

G\Gja/a-D\aja/G-n\njn/a-a\a|a/n-n\n|n/G-D\Q|n/a-a\G|G/a-n\D|a/a-a\a|D/D-a\a|Q/n-n\a|Q/n- 

a\njn/n-D\a|a/G-n\n|n/n-G\G|G/D-D\a|D/G-a\a|G/a-a\D|n/n-n\njG/n-a\a|n/G-D\D|a/D-a\D|a/D- 

a\G|n/a-a\a|a/n-n\n|n/n-n\n|G/G-a\G|G/a-a\D|a/a-a\G|a/G-G\n|G/n-a\a[a/a-a\a|a/a-D\D|D/n- 

a\a|n/G-a\a|a/a-n\n|D/a-G\a|G/a-a\G|D/a-G\D|G/a-G\n|a/a-Q\a|Q/a-a\a|a/a-G\a|D/a-a\D|a/a- 

□\D|D/D-a\D|D/D-n\n|n/n-n\D|a/D-a\a|D/D-a\D|a/a-n\a|D/a-a\n|D/a-D\DjD/D-D\D|D/D-o\n|a/a- 

□\D|n/D-n\D|D/D-a\a|a/n-D\Dja/D-D\D|D/D-a\D|D/D-n\n|D/D-a\n|a/a-D\D|D/D-D\D|a/D-D\Dfa/n- 

□\a|n/D-D\D|n/D-n\n|D/a-D\D|D/D-D\a|a/a-n\D|D/D-a\a|D/D-D\D|a/n-n\n|n/n-c\n|n/a-n\D|D/a- 

□\D|a/D-D\a|D/a-a\D|a/D^ 

□\D|a/D-n\D|n/a-D\D|n/D-n\^^ 

□\D|a/D-D\D|D/a-D\a|D/a-a^ 

n\D|n/n-n\D|n/n-D\a^ 

□vnia/n-a\D|a/D-D\D|a/n-a\n|n/a-n\D|a/n-D\n|n/n-n\n|n/n-a\n|D/a-n\n|D/a-a\D|n/n-n\D|a/n 

(02:05:41.08) 

Tester mode is ON. 
Tester mode is ON. 

LVS option is ON. 

Reading File : /dev/null listing file name : 'spice. 1st' 

(00:00:01.34) 

MicroUnity Spice Interface run on Feb 25 22:51 :1 1995 
DESIGN NAME : 'EUTERPE_PA SS 1 ' 
DESIGN COMPILATION ON Feb 25 22:51:4 1995 


3 errors detected 
1 oversights detected 
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Now it complains of 3 errors and 1 oversight, yet I see no error, and: 

<lnk>#l OVERSIGHT(127): ABBREV property not found for drawing 
Drawing: M IOFFLOAD".SPICE.l 

No parameters 
Generated abbreviation: FFL 

<lnk>#2 OVERSIGHT(127): ABBREV property not found for drawing 
Drawing: "IOCLKWART". SPICE. 1 

No parameters 
Generated abbreviation: CLK 

<1nk>#3 OVERSIGHT(127): ABBREV property not found for drawing 
Drawing: "IOQUADDELAY".SPICE.l 

No parameters 
Generated abbreviation: QDD 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, February 26, 1995 12:19 PM 

'craig (Craig Hansen)' 

'age' 

Re: Hermes with Cronus 


Craig Hansen wrote (on Wed Feb 22) : 

Given that Mnemosyne is operating at half the rate of its 
original target, I think it's also worth considering such a 
change in Mnemosyne itself. As to the rate flexibility on 
Cronus, it's worth considering a power-of-two rate control, 
which could also avoid a PLL - also the higher rate Hermes 
channel should be considered for a rev of Euterpe (such as 
the Cronus ->MOBIMOS remap part) . 

Remember we had an original (MU internal) target of 1GHz clock on the channel *and* 
internally on the first design. We had an externally committed goal of 500MHz, and our 
best analysis said we made 550MHz. 

The new Mnemo has been designed assuming a 2x ratio between the internal clock and the 
channel clock. We have extended the lower range of the PLL to ensure we will be able to 
operate down to the low end of what the current Euterpe can do, in order to be able to run 
in powered down standby mode. (Bupassing the PLL is no use in this case, without a 
separate 2x clock input with carefully controlled phase. 

This path being provided only for test.) So we have already designed it to get the most 
from the internal logic, given the current performance of the channel. 

On Cronus, the issue is very much whether we think we can get 80 0MB/s through the CMOS 
interface (when RAMBUS have yet to get 5 0 0MB/s working reliably) . We are going to try, 
but I agree it would be wise to have a fallback position at half rate. However, I do feel 
strongly, that with only 4 00MB/s (ie 2 00MHz Hermes clock) we would have a secondary cache 
access time longer than most people's DRAM accesss time, which would be an embarrassement . 
It seems to me the channel architecture does not make sense at low speed. 

At this point I'm not sure if what you are suggesting is that we should design a Mnemo to 
support a 1GHz channel clock (ie 2GB/ s data 

rate) on the interface (which would be a complete redesign to double up all the internal 
bandwidths) , or that we should assume we have to run with a Cronus Hermes channel at 
2 0 0MHz and therefore design Mnemo with half the internal number of pipeline stages to cut 
the latency in that case. The former would be just a lot of additional work (alan can 
comment on how much) , but the latter would require a fundamental change to the 
methodology, because the current wide gate family is limited to 2 gates between level 
restoring elements (ie flops) . 


Tim 
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From: hopper (Mark Hofmann) 

Sent: Sunday, February 26, 1995 1:45 PM 

To: 'Geert Rosseel' 

Subject: Re: Toplevel Euterpe 


Geert Rosseel writes: 
Hi, 

I rebuild the top-level and it is worse than it was before. We are back at 4300 
un- routes, up from 3 500. 

[snip] 

Geert - 

Did the hcO run complete early enough for you to try that at the top-level? 
I was wondering if the new layout helped or hurt. 

-thanks, 
mark 
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From: tbr 

Sent: Sunday, February 26, 1995 1 :57 PM 

To: 'brianl' 

Cc: 'age'; Vo' 

Subject: more missing data 

Follow Up Flag: Follow up 

Flag Status: Red 


Looks like we are missing capacitance data for mb in mnemo. 
I don't know if this is a problem because we may be forcing all the 
interfaces, but we ought to be treating this the same way as we do the 
caches in euterpe. Can you check please? 


Tim 

Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning 
Warning 
Warning! 
Warning! 
Warning! 
Warning! 
Warning! 
Warning 
Warning! 
Warning! 
Warning! 


No a_AD0PF<13> pin capacitance data for mb 
No a_AD0PF<12> pin capacitance data for mb 
No a_AD0PF<l I> pin capacitance data for mb 
No a_AD0PF<10> pin capacitance data for mb 
No a_AD0PF<9> pin capacitance data for mb 
No a_AD0PF<8> pin capacitance data for mb 
No a_AD0PF<7> pin capacitance data for mb 
No a_AD0PF<6> pin capacitance data for mb 
No a_AD0PF<5> pin capacitance data for mb 
No a_AD0PF<4> pin capacitance data for mb 
No a_AD0PF<3> pin capacitance data for mb 
No a_AD0PF<2> pin capacitance data for mb 
No a_AD0PF<l> pin capacitance data for mb 
No a_AD0PF<0> pin capacitance data for mb 
No a_AND0PF<13> pin capacitance data for mb 
No a_AND0PF<12> pin capacitance data for mb 
No a_ANDOPF<l 1> pin capacitance data for mb 
No a_AND0PF<10> pin capacitance data for mb 
No a_AND0PF<9> pin capacitance data for mb 
No a_AND0PF<8> pin capacitance data for mb 
No a_AND0PF<7> pin capacitance data for mb 
No a_AND0PF<6> pin capacitance data for mb 
No a_AND0PF<5> pin capacitance data for mb 
No a_AND0PF<4> pin capacitance data for mb 
No a_AND0PF<3> pin capacitance data for mb 
No a_AND0PF<2> pin capacitance data for mb 
No a AND0PF<1> pin capacitance data for mb 
No a AND0PF<0> pin capacitance data for mb 
No din_AD0PF<21> pin capacitance data for mb 
No din_ADOPF<20> pin capacitance data for mb 
No din_AD0PF<19> pin capacitance data for mb 
No din_ADOPF<l 8> pin capacitance data for mb 
No din_AD0PF<17> pin capacitance data for mb 
No din_AD0PF<16> pin capacitance data for mb 
No din_AD0PF<15> pin capacitance data for mb 
No din_AD0PF<14> pin capacitance data for mb 
No din_AD0PF<13> pin capacitance data for mb 
No din_AD0PF<12> pin capacitance data for mb 
No din_ADOPF<l 1> pin capacitance data for mb 
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Warning! No din_ADOPF<10> pin capacitance data for mb 
Warning! No din_AD0PF<9> pin capacitance data for mb 
Warning! No din_AD0PF<8> pin capacitance data for mb 
Warning! No din_AD0PF<7> pin capacitance data for mb 
Warning! No din_AD0PF<6> pin capacitance data for mb 
Warning! No din_AD0PF<5> pin capacitance data for mb 
Warning! No din_AD0PF<4> pin capacitance data for mb 
Warning! No din_AD0PF<3> pin capacitance data for mb 
Warning! No din_AD0PF<2> pin capacitance data for mb 
Warning! No din_ADOPF<l> pin capacitance data for mb 
Warning! No din_ADOPF<0> pin capacitance data for mb 
Warning! No din_AND0PF<2 1 > pin capacitance data for mb 
Warning! No din_AND0PF<20> pin capacitance data for mb 
Warning! No din_AND0PF<19> pin capacitance data for mb 
Warning! No din_ANDOPF<l 8> pin capacitance data for mb 
Warning! No din_AND0PF<t7> pin capacitance data for mb 
Warning! No din_AND0PF<16> pin capacitance data for mb 
Warning! No din_ANDOPF<l 5> pin capacitance data for mb 
Warning! No din AND0PF<14> pin capacitance data for mb 
Warning! No din_AND0PF<13> pin capacitance data for mb 
Warning! No din_AND0PF<12> pin capacitance data for mb 
Warning! No din_ANDOPF<l 1> pin capacitance data for mb 
Warning! No din_AND0PF<10> pin capacitance data for mb 
Warning! No din_AND0PF<9> pin capacitance data for mb 
Warning! No din_AND0PF<8> pin capacitance data for mb 
Warning! No din_AND0PF<7> pin capacitance data for mb 
Warning! No din_AND0PF<6> pin capacitance data for mb 
Warning! No din_AND0PF<5> pin capacitance data for mb 
Warning! No din_AND0PF<4> pin capacitance data for mb 
Warning! No din AND0PF<3> pin capacitance data for mb 
Warning! No din_AND0PF<2> pin capacitance data for mb 
Warning! No din_ANDOPF<l> pin capacitance data for mb 
Warning! No din_ANDOPF<0> pin capacitance data for mb 
Warning! No VFF<2> pin capacitance data for mb 
Warning! No VFF<1> pin capacitance data for mb 
Warning! No VFF<0> pin capacitance data for mb 
Warning! No VRR<2> pin capacitance data for mb 
Warning! No VRR<I> pin capacitance data for mb 
Warning! No VRR<0> pin capacitance data for mb 
Warning! No WE_AN0PF<1> pin capacitance data for mb 
Warning! No WE_AN0PF<0> pin capacitance data for mb 
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From: geert (Geert Rosseel) 

Sent: Sunday, February 26, 1995 6:14 PM 

To: 'billz'; 'dickson'; 'hopper'; 'mws'; 'tbr*; 'vo'; 'woody' 

Cc: 'lisaf 

Subject: Toplevel Euterpe 

Hi, 

I rebuild the top-level and it is worse than it was before. We are back at 4300 
un-routes, up from 3500. 

Tom Vo's changes to cerberus have helped. The congestion at the top-right of 
cerberus is largely gone. 

I had to include a very bad uu in this run, That added a lot of un-routes. When I 
gaet a better uu, I'll rebuild again. 

I cannot see very well how much Rich's changes helped. There is still quite 
a bit of congestion in the control section. 

DR. also needs some work, if we want it to route better using line-search only. 

We also still need to do more work on the stripe next to the I -cache. There are 
probably still about 100 nets that cannot route. 


Geert 
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From: tor 

Sent: Sunday, February 26, 1995 6:18 PM 

To: 'geert (Geert Rosseel)' 

Cc: 'billz'; 'dickson'; 'hopper'; 'lisar'; 'mws'; 'vo'; 'woody' 

Subject: Toplevel Euterpe 
Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Sun Feb 26): 


Hi, 

I rebuild the top-level and it is worse than it was before. We are back at 4300 
un-routes, up from 3500. 

Tom Vo's changes to cerberus have helped. The congestion at the top-right of 
cerberus is largely gone. 

Somnething positive at least! 

I had to include a very bad uu in this run, That added a lot of un-routes. When I 
gaet a better uu, I'll rebuild again. 

I cannot see very well how much Rich's changes helped. There is still quite 
a bit of congestion in the control section. 

DR also needs some work, if we want it to route better using line-search only. 

We also still need to do more work on the stripe next to the I-cache. There are 
probably still about 100 nets that cannot route. 

Sounds like we should get plots of the offending areas and compare 
them with the ones from the last run. Is it possible we still have a 
systematic target problem such that rich's changes are not helping? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, February 26, 1995 6:18 PM 

'geert (Geert Rosseel)' 

'billz'; 'dickson'; 'hopper'; 'lisar'; 'mws'; Vo'; 'woody' 
Toplevel Euterpe 


Geert Rosseel wrote (on Sun Feb 26) : 


Hi, 


I rebuild the top-level and it is worse than it was before. We are back, at 4 300 
un- routes, up from 3500. 

Tom Vo's changes to cerberus have helped. The congestion at the top- right of 
cerberus is largely gone. 

Somnething positive at least I 

I had to include a very bad uu in this run, That added a lot of un-routes. When I 
gaet a better uu, I'll rebuild again. 

I cannot see very well how much Rich's changes helped. There is still quite 
a bit of congestion in the control section. 

DR also needs some work, if we want it to route better using line- search only. 

We also still need to do more work on the stripe next to the I-cache. 
There are 

probably still about 100 nets that cannot route. 

Sounds like we should get plots of the offending areas and compare them with the ones from 
the last run. Is it possible we still have a systematic target problem such that rich's 
changes are not helping? 


Tim 
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From: 


tbr 


To: 

Cc: 

Subject: 


Sent: 


Sunday, February 26, 1995 6:52 PM 
'wingard (Drew Wingard)' 
'sysadmin' 

Need old files from backup tape 


Follow Up Flag: Follow up 
Flag Status: Red 

Did these come back OK? 

Drew Wingard wrote (on Fri Feb 24): 

I need to resurrect an old program. I saved the code, but managed to delete 
the configuration files and examples. 

Can you please install: 

/n/auspex/s24/wingard/chip/ca!liope/verilog/src 
and 

/n/auspex/s24/w ingard/chip/euterpe/veri log/bsr c 
someplace where I can access them? 

My recollection is that they occupy approx 300 MBytes (which is why they 
were deleted...). 

None of the files that I care about were modified after May 26th last year. 

Best Regards, 
Drew 
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Subject: 


Sent: 

To: 

Cc: 


From: 


woody (Jay Tomlinson) 

Sunday, February 26, 1995 9:36 PM 

'geert (Geert Rosseel)' 

'billz'; 'dickson'; 'hopper'; 'lisar'; 'mws'; 'tbr'; 'vo' 
Toplevel Euterpe 


Geert Rosseel wrote (on Sun Feb 26) : 


Hi, 


I rebuild the top-level and it is worse than it was before. We are back at 4300 
un- routes, up from 3500. 

Tom Vo's changes to cerberus have helped. The congestion at the top-right of 
cerberus is largely gone. 

I had to include a very bad uu in this run, That added a lot of un- routes. When I 
gaet a better uu, I'll rebuild again. 

Is there something besides the extra width? 


woody 
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From: geert (Geert Rosseel) 

Sent: Sunday, February 26, 1 995 1 0:37 PM 

To: "woody' 

Cc: 'billz'; 'dickson'; 'hopper 1 ; lisar'; 'mws'; 'tbr'; Vo" 
Subject: Re: Toplevel Euterpe 

> Is there something besides the extra width? 

Well, I couldn't make it fit so I had to place the remaining cells 
where there was some room but I am sure the placement was fair from 
optimal. There were a lot more disconnects in uu now than before. 

Geert 
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From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Sunday, February 26, 1995 10:54 PM 
'geert (Geert Rosseel)' 

'billz'; 'dickson'; 'hopper'; 'lisar'; 'mws'; Vo'; 'woody' 
Re: Toplevel Euterpe 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sun Feb 26): 

> Is there something besides the extra width? 

Well, I couldn't make it fit so I had to place the remaining cells 
where there was some room but I am sure the placement was farr from 
optimal. There were a lot more disconnects in uu now than before. 

What did it do stand alone? If it's not routing there to completion 
it never will at the top with other stuff going through it. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, February 26, 1995 10:54 PM 

'geert (Geert Rosseel)' 

'billz'; 'dickson'; 'hopper'; 'lisar'; 'mws'; 'vo'; 'woody' 
Re: Toplevel Euterpe 


Geert Rosseel wrote (on Sun Feb 26) : 

> is there something besides the extra width? 

Well, I couldn't make it fit so I had to place the remaining cells 
where there was some room but I am sure the placement was farr from 
optimal. There were a lot more disconnects in uu now than before. 

What did it do stand alone? If it's not routing there to completion it never will at the 
top with other stuff going through it. 


Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


woody (Jay Tomlinson) 

Sunday, February 26, 1995 11:38 PM 

'tbr (Tim B. Robinson)' 

'billz'; 'dickson'; 'geert (Geert Rosseel)'; 'hopper'; 'lisar*; 'mws'; 'vo' 
Re: Toplevel Euterpe 


Tim B. Robinson wrote (on Sun Feb 26) : 

Geert Rosseel wrote {on Sun Feb 26) : 

> Is there something besides the extra width? 

Well, I couldn't make it fit so I had to place the remaining cells 
where there was some room but I am sure the placement was farr from 
optimal. There were a lot more disconnects in uu now than before. 

What did it do stand alone? If it's not routing there to completion 
it never will at the top with other stuff going through it. 


It routes, but fail in -iter due to timing violations. Since the last few weeks I have 
been working on bug fixes, I never get a chance to work on the problem. 


Tim 


woody 
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From: wingard (Drew Wingard) 

Sent: Monday, February 27, 1995 12:14 AM 

To: tbr* 

Cc: 'sysadmin' 

Subject: Re: Need old files from backup tape 
Tbr wrote: 

> Did these come back OK? 

> 

> Drew Wingard wrote (on Fri Feb 24): 

> 

> I need to resurrect an old program. I saved the code, but managed to delete 

> the configuration files and examples. 

> 

> Can you please install: 

> /n/auspex/s24/wingard/ch ip/cal liope/veri log/src 

> and 

> /n/auspex/s24/wingard/chip/euterpe/verilog/bsrc 

> someplace where I can access them? 

> 

> My recollection is that they occupy approx 300 MBytes (which is why they 

> were deleted...). 

> 

> None of the files that I care about were modified after May 26th last year. 

> 

> Best Regards, 

> Drew 

Yes they did. Ken took care of me. 

Thanks for checking! 

Drew 
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From: lisar (Lisa Robinson) 

Sent: Monday, February 27, 1995 12:57 AM 

To: 'mws (Mark Semmelmeyer)' 

Cc: 'billz'; 'dickson'; 'jeffm'; 'mws 1 ; 'tbr'; 'woody' 

Subject: Re: Test status / exlocktest 


Mark Semmelmeyer wrote (on Sun Feb 26): 

Lisa rebuilt a ex!ocktest_0 trace for me. 
As best as I can tell, r58 (the running count 
of number of exceptions) is never initialized, 
eventually X corrupts the 1st conditional branch 
in the excl_start section of code when it tries 
to check for exactly 3 exceptions. 

Now the test goes to BAD see the trace in /s3/euterpe/verilog/bsrc/res/26295.17807/results/exlocktest_0.dpo 

Hope I fixed it correctly. 

Lisa R. 
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From: brianl (Brian Lee) 

Sent: Monday, February 27, 1 995 1 1 :22 AM 

To: Tim B. Robinson' 

Subject: Re: more missing data 

Tim B. Robinson writes: 
I 

|Looks like we are missing capacitance data for mb in mnemo. 
jl don't know if this is a problem because we may be forcing all the 
j interfaces, but we ought to be treating this the same way as we do the 
leaches in euterpe. Can you check please? 
I 

|Tim 

OK. We don't have data for this yet. Who should I ask for the information? 
Brian 


| Warning! No a_AD0PF<13> pin capacitance data for mb 
(Warning! No a_AD0PF<12> pin capacitance data for mb 
j Warning! No a_AD0PF<l 1> pin capacitance data for mb 
j Warning! No a_AD0PF<10> pin capacitance data for mb 
(Warning! No a_AD0PF<9> pin capacitance data for mb 
| Warning! No a_AD0PF<8> pin capacitance data for mb 
jWarning! No a_AD0PF<7> pin capacitance data for mb 
(Warning! No a_AD0PF<6> pin capacitance data for mb 
j Warning! No a_AD0PF<5> pin capacitance data for mb 
j Warning! No a_AD0PF<4> pin capacitance data for mb 
(Warning! No a_AD0PF<3> pin capacitance data for mb 
{Warning! No a AD0PF<2> pin capacitance data for mb 
j Warning! No a_AD0PF<l> pin capacitance data for mb 
| Warning! No a_AD0PF<0> pin capacitance data for mb 
j Warning! No a_AND0PF<13> pin capacitance data for mb 
(Warning! No a_AND0PF<12> pin capacitance data for mb 
(Warning! No a AND0PF<1 1> pin capacitance data for mb 
j Warning! No a_AND0PF<10> pin capacitance data for mb 
j Warning! No a_AND0PF<9> pin capacitance data for mb 
j Warning! No a_AND0PF<8> pin capacitance data for mb 
(Warning! No a_AND0PF<7> pin capacitance data for mb 
[Warning! No a_AND0PF<6> pin capacitance data for mb 
| Warning! No a AND0PF<5> pin capacitance data for mb 
j Warning! No a_AND0PF<4> pin capacitance data formb 
j Warning! No a_AND0PF<3> pin capacitance data for mb 
j Warning! No a_AND0PF<2> pin capacitance data for mb 
j Warning! No a_AND0PF<l> pin capacitance data for mb 
I Warning! No a_AND0PF<0> pin capacitance data for mb 
(Warning! No din_AD0PF<2 1> pin capacitance data for mb 
j Warning! No din_ADOPF<20> pin capacitance data for mb 
j Warning! No din_AD0PF<19> pin capacitance data for mb 
j Warning! No din_ADOPF<l 8> pin capacitance data for mb 
j Warning! No din_AD0PF<17> pin capacitance data for mb 
| Warning! No din_AD0PF<16> pin capacitance data for mb 
| Warning! No din_AD0PF<15> pin capacitance data for mb 
j Warning! No din_AD0PF<14> pin capacitance data for mb 
[Warning! No din_AD0PF<13> pin capacitance data for mb 
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I Warning! No din_AD0PF<12> pin capacitance data for mb 
j Warning! No din_ADOPF<l 1> pin capacitance data for mb 
j Warning! No din_AD0PF<10> pin capacitance data for mb 
j Warning! No din_AD0PF<9> pin capacitance data for mb 
j Warning! No din_AD0PF<8> pin capacitance data for mb 
IWarning! No din_AD0PF<7> pin capacitance data for mb 
| Warning! No din_AD0PF<6> pin capacitance data for mb 
| Warning! No din_AD0PF<5> pin capacitance data for mb 
IWarning! No din_AD0PF<4> pin capacitance data for mb 
j Warning! No din AD0PF<3> pin capacitance data for mb 
IWarning! No din_AD0PF<2> pin capacitance data for mb 
j Warning! No din_ADOPF<l> pin capacitance data for mb 
j Warning! No din_AD0PF<0> pin capacitance data for mb 
[Warning! No din_AND0PF<2 1> pin capacitance data for mb 
[Warning! No din_AND0PF<20> pin capacitance data for mb 
[Warning! No din_AND0PF<19> pin capacitance data for mb 
[Warning! No din_AND0PF<18> pin capacitance data for mb 
[Warning! No din_ANDOPF< 1 7> pin capacitance data for mb 
[Warning! No din_AND0PF<16> pin capacitance data for mb 
[Warning! No din_AND0PF<15> pin capacitance data for mb 
[Warning! No din_AND0PF<14> pin capacitance data for mb 
[Warning! No din_AND0PF<13> pin capacitance data for mb 
[Warning! No din_AND0PF<12> pin capacitance data for mb 
j Warning! No din_ANDOPF<l 1> pin capacitance data for mb 
[Warning! No din_AND0PF<10> pin capacitance data for mb 
j Warning! No din_AND0PF<9> pin capacitance data for mb 
[Warning! No din_AND0PF<8> pin capacitance data for mb 
j Warning! No din_AND0PF<7> pin capacitance data for mb 
[Warning! No din_AND0PF<6> pin capacitance data for mb 
[Warning! No din_AND0PF<5> pin capacitance data for mb 
[Warning! No din_AND0PF<4> pin capacitance data for mb 
[Warning! No din_AND0PF<3> pin capacitance data for mb 
[Warning! No din_AND0PF<2> pin capacitance data for mb 
IWarning! No din_ANDOPF<l> pin capacitance data for mb 
[Warning! No din_ANDOPF<0> pin capacitance data for mb 
j Warning! No VFF<2> pin capacitance data for mb 
j Warning! No VFF<1> pin capacitance data for mb 
j Warning! No VFF<0> pin capacitance data for mb 
j Warning! No VRR<2> pin capacitance data for mb 
j Warning! No VRR<1> pin capacitance data for mb 
j Warning! No VRR<0> pin capacitance data for mb 
IWarning! No WE_AN0PF<1> pin capacitance data for mb 
IWarning! No WE_ANOPF<0> pin capacitance data for mb 
I 


Brian L. 


Exhibit Cll 


Page 526 of 559 


To: 


From: 


Sent: 


torn (Tom Laidig (tau)) 

Monday, February 27, 1995 11:36 AM 

Tim B. Robinson' 


Cc: 'tau' 

Subject: Re: staypuft:/s3 

Tim B. Robinson writes: 
I 

| We seem to be thrashing for disk space in staypuft:/s3. 

1 1 had built a new euterpe environment there after the new space came on line, 

jso we had another place to run verilog simulations with huge dump 

jfiles (-5 00MB), but the Creole stuff has stolen that (and I suspext a 

jbuild I was doing last night which failed in topt would have been 

jbecause of disk space, but I'm not certain because there is about 

j 130MB there now). 

Hmmm... I was asking around about a place where I could build the Creole 
tape (requires -800MB to complete), and someone (hopper? not sure) 
suggested the new disk on staypuft. Oh, well... 

I 

|How close is the Creole build to being done, and how much more space 
jwill you need? Currently we do have a lot of space on nosferatu. 

I'm declaring it done now, except that the final tar file building 
didn't complete because the disk filled. I should have that file built 
(on one of clio's disks) in a few hours, at which time I'll delete the 
rest. 
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To: 

Subject: 


Sent: 


From: 


tbr 

Monday, February 27, 1995 11:50 AM 
'brianl (Brian Lee)' 
Re: more missing data 


Follow Up Flag: Follow up 
Flag Status: Red 

Brian Lee wrote (on Mon Feb 27): 

Tim B. Robinson writes: 

I 

J Looks like we are missing capacitance data for mb in mnemo. 
jl don't know if this is a problem because we may be forcing all the 
(interfaces, but we ought to be treating this the same way as we do the 
| caches in euterpe. Can you check please? 
I 

|Tim 

OK. We don't have data for this yet. Who should I ask for the information? 
Either bruce or bp, but i'm not sure which. 


Tim 


Exhibit Cll 


Page 528 of 559 


From: bill (William Herndon) 

Sent: Monday, February 27, 1995 5:41 PM 

To: 'tbr@microu nity.com'; 'solo' 

Cc: 'torn'; 'yves'; 'lisar' 

Subject: Re: proteus/ged/BOM 

> From solo Mon Feb 27 14:59:20 1995 

> From: solo (John Campbell) 

> Subject: Re: proteus/ged/BOM 

> To: tbr@echidna.microunity.com (Tim B. Robinson) 

> Date: Mon, 27 Feb 95 14:59:14 PST 

> Cc: torn (Thomas Laidig), yves (Jean- Yves Michel), bill (William Herndon), 

> lisar (Lisa Robinson) 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content-Length: 2982 

> 

> as Tim B. Robinson was saying 

> .. 
> ,. 

> ..cvs update: New directory ^bellybutt 1 — ignored 

> .. 

> ..Are these all obsolete? If not, do we know why they are not in the 

> ..BOM? 

> .. 

> ..Also, and perhaps more worrying, the following changes are unreleased: 
> .. 

> 

> i did a cvs log and included the last two entries, none of these 

> should make a difference if the log accurately reflects what was done. 

> looks like bill was trying to sanitize the labeling probably for 

> consistency. 

> 

> the rastagel was removal of layout_equiv which shouldn't affect 

> anything except running Ivs on iss. 

> 

> looks like we could release these three with no side effects. 

> 

> i was wrong on bellybutt. the custom cell iobytem uses iobellybutt. 

> only mb uses bellybutt. therefore, it didn't get bom'ed without mb. 

> 

I think i was trying to make some Ivs come out and needed a label., in any 
case the label on the output current switch doesn't affect the operation 
of the circuit., the date 11/22/94 bothers me i don't recall doing anything 
with the clock on those dates.. 

I want to make sure that in the euterpe clock tree we are using cged and cgeb 
not cgdr and cgbfr.. 

> ..U cg/cgbfr/spice.1.1 

> revision 1.5 

> date: 1994/11/22 13:30:30 LT; author: bill; state: Exp; lines: +191 -187 

> output switch label eout 

> 
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> revision 1 .4 

> date: 1993/12/10 11:24:17 LT; author: bill; state: Exp; lines: +231 -231 

> added w to output pin names to allow emitter dot 

> 
> 

> ..U cg/cgbfr/spice_cn.1.1 

> . 

> revision 1.5 

> date: 1994/11/22 13:30:32 LT; author: bill; state: Exp; lines: +84 -83 

> output switch label eout 


> revision 1.4 

>date: 1993/12/10 11:24:19 LT; author: bill; state: Exp; lines: +92 -92 

> added w to output pin names to allow emitter dot 

> 
> 

> .cvs update: Updating cg/cgdr 

> ..U cg/cgdr/spice.1.1 


> revision 1.3 

> date: 1994/1 1/22 13:29:43 LT; author: bill; state: Exp; lines: +302 -298 

> output switch current label eout 


> revision 1.2 

> date: 1993/07/27 13:37:53 LT; author: bill; state: Exp; lines: +144-136 

> misrc replaced with std current source 

> 

> ..U cg/cgdr/spice_cn.l.l 

> 

> 

> revision 1.3 

> date: 1994/11/22 13:29:45 LT; author: bill; state: Exp; lines: +124 -123 

> output switch current label eout 

> revision 1.2 

>date: 1993/07/27 13:37:55 LT; author: bill; state: Exp; lines: +98-96 

> misrc replaced with std current source 

> 

> . .U ra/rastage 1 /spice. 1 . 1 


> revision 1.4 

>date: 1994/03/04 18:13:37 LT; author: solo; state: Exp; lines: +475 -479 

> modified schem to remove layout_equiv. must use exp list for rastagel 
> 

> revision 1 .3 

>date: 1994/02/14 10:54:52 LT; author: yves; state: Exp; lines: +476 -448 

> Added Vpp signal 

> 

> 

> ..U ra/rastage l/spice_cn. 1 . 1 

> 

> 

> revision 1 .4 

>date: 1994/03/04 18:13:41 LT; author: solo; state: Exp; lines: +131 -132 

> modified schem to remove layout_equiv. must use exp list for rastagel 

> revision 1.3 

> date: 1994/02/14 10:54:55 LT; author: yves; state: Exp; lines: +160-151 

> Added Vpp signal 
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> ..Tim 
> .. 

> 
> 

> .... 

> regards, 

> solo a. k . a. John Campbe 11 x5 1 6 

> 
> 
> 
> 
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From: wampler (Kurt Wampler) 

Sent: Monday, February 27, 1 995 6: 1 3 PM 

To: 'geert' 

Subject: More early nets? 


Looking at the latest top-level Euterpe route, I see another bus that may be a candidate 
for "early" routing: 

hcrawdata* 

Also, it looks like the upper-right corridor is still full of M3 and needs more wire 
reduction before all the wires will make it through. 

Other than these observations, I'm sort of at a loss to suggest what to do next... 
- Kurt 
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From: dickson (Richard Dickson) 

Sent: Monday, February 27, 1995 7:04 PM 

To: 'geeif 

Subject: iq 


geert , 

my route of mws's iq hack is complete, 
it went from 9-5 k atoms to 5.6 atoms so there should be more routing channels available, 
this new layout is at dickson/euterpe/verilog/bsrc/iq 

dickson 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Monday, February 27, 1995 10:30 PM 

'torn (Tom Laidig (tail)' 

'tau' 

Re: staypuft:/s3 


Follow Up Flag: Follow up 
Flag Status: Red 

tau wrote (on Mon Feb 27): 

Tim B. Robinson writes: 

I 

| We seem to be thrashing for disk space in staypuft:/s3. 

j I had built a new euterpe environment there after the new space came on line, 

jso we had another place to run verilog simulations with huge dump 

|files (-500MB), but the Creole stuff has stolen that (and I suspext a 

jbuild I was doing last night which failed in topt would have been 

jbecause of disk space, but I'm not certain because there is about 

| BOMB there now). 

Hmmm... 1 was asking around about a place where 1 could build the Creole 
tape (requires -800MB to complete), and someone (hopper? not sure) 
suggested the new disk on staypuft. Oh, well... 

Not to worry. I move a whole bunch of stuff in there without 
realizing you were using up the same space! 

I 

|How close is the Creole build to being done, and how much more space 
jwill you need? Currently we do have a lot of space on nosferatu. 

I'm declaring it done now, except that the final tar file building 
didn't complete because the disk filled. I should have that file built 
(on one of clio's disks) in a few hours, at which time I'll delete the 
rest. 

Great, thanks 
Tim 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, February 28, 1995 12:44 AM 

To: 'mws' 

Cc: 'jeffm'; 'tbr* 

Subject: exlocktest 

Dump on staypuft /s3/tbr/euterpe/verilog/bsrc/exlocktest_0.* 
Lisa R, 
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From: tbr 

Sent: Tuesday, February 28, 1995 12:48 AM 

To: 'bill (William Herndon)' 

Cc: 'lisar'; 'solo'; 'torn'; 'yves' 

Subject: Re: proteus/ged/BOM 

Follow Up Flag: Follow up 

Flag Status: Red 


William Herndon wrote (on Mon Feb 27): 


> From solo Mon Feb 27 14:59:20 1995 

> From: solo (John Campbell) 

> Subject: Re: proteus/ged/BOM 

> To: tbr@echidna.microunity.com (Tim B. Robinson) 

> Date: Mon, 27 Feb 95 14:59: 14 PST 

> Cc: torn (Thomas Laidig), yves (Jean- Yves Michel), bill (William Herndon), 

> lisar (Lisa Robinson) 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content- Length: 2982 

> 

> as Tim B. Robinson was saying 

> .. 

> .. 

> ..cvs update: New directory 'bellybutt' — ignored 

> .. 

> ..Are these all obsolete? If not, do we know why they are not in the 

> ..BOM? 

> .. 

> ..Also, and perhaps more worrying, the following changes are unreleased: 

> .. 

> 

> i did a cvs log and included the last two entries, none of these 

> should make a difference if the log accurately reflects what was done. 

> looks like bill was trying to sanitize the labeling probably for 

> consistency. 

> 

> the rastagel was removal of layout_equiv which shouldn't affect 

> anything except running lvs on iss. 

> 

> looks like we could release these three with no side effects. 

> 

> i was wrong on belly butt, the custom cell iobytem uses iobellybutt. 

> only mb uses bellybutt. therefore, it didn't get bom'ed without mb. 

> 

I think i was trying to make some lvs come out and needed a label., in any 
case the label on the output current switch doesn't affect the operation 
of the circuit., the date 11/22/94 bothers me i don't recall doing anything 
with the clock on those dates.. 

I want to make sure that in the euterpe clock tree we are using cged and cgeb 
not cgdr and cgbfr.. 
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We are, but there are instances of cgdr in the design somewhere also. 
I see it get compiled when making an LVS netlist: 

Compiling CGDR.SPICE. 1 . 1 
No parameters 

No errors detected 
No oversights detected 
No warnings detected 

Page compiled (00:00:00.78) 

But I can't put a fmger on where it's being used. 

Tim 


Exhibit Cll 


Page 537 of 559 


From: lisar (Lisa Robinson) 

Sent: Tuesday, February 28, 1 995 9:18 AM 

To: 'billz'; 'dickson'; 'jeffm'; , mws'; 'tbr'; 'woody 1 

Cc: 'geert' 

Subject: Test Status 


BOM 240 running on Zycad 
BOM 240 running on IKOS 

NOTE: addr map dtag, addr_map_itag and uncruptharder Ran okay 


New business 


regdepend_r25547 238 - miscompare on gmshril 6 (should take an exception but doesn't) 
tried to recreate with same operands but ran ok 


brmisstest_0 

meml 

gtlbtran_l 

exrleasy_0 
exlocktest_0 

barrel_l 

gtlb_miss„l 

bgate_l 

fva_conflict_l 
nb_l 

nb_hermes_l 
alignatl 
unix 1 


238.1 1 - X trace on rhodan /s3 25295.24677 ran in verilog one cyl fabbed 

238.1 1 - Hung trace on rhodan /s3 25295.24948 

231 - Unexpected exception 1 1 at PC 0x800000c0t5cb cyl 0 
trace on nosferatu /s2 18295.14022 
23 1 - Hung - understood trace rhodan on /s3 17295.4484 

240 - BAD - trace on rhodan /s3 26295.14922 verilog dump on staypuft /s3/tbr/euterpe/verilog/bsrc 

236 - } Ran for 100K cycles in verilog ie passed the going to X 
238.1 1 - Still goes to X - trace on rhodan /s3 25295.25980 (note reads x from sdram) 
228.1 1 - rhodan /s3 25295.26559 

236 - } Traces on rhodan /s3 22295.29856 

240 - Stuck in a loop - trace on rhodan /s3 26295.13087 
240 - Stuck in a loop - trace on rhodan /s3 26295. 13858 

240 - Test doesn't enable hermes channels - trace on nosferatu /s2 26295.23710 
240 - Failed smux64lai! Test needs updating 
240 - X - trace on rhodan /s3 26295.14084 


addr map_sysreg J 240 - Bad rhodan /s3 27295 . 1 646 


dcache_func_l 
icache fiinc 1 


238.1 1 - trace on rhodan /s3 24295.14636 
228 - trace on rhodan /s3 23295.151 10 


dcache_sz_4k_l 238.11 -} 

dcache„sz_8k_l 238.11 - } traces on rhodan /s3 24295.13892 
dcache_sz_16kj 238.11 -} 

icache_sz_4k_l 238 - } Traces on rhodan /s3 22295.9305 
icache_sz_8k_l 238 - } 
icache_sz_16k_l 238 - } 

bgate_U 238 - Hung look at pc its 0? trace on rhodan /s3 22295.87 14 

dcache_perf_st 1 1 1 240 - X trace on rhodan /s3 26295. 1 43 1 4 
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dcache_perf_ldst5M 240 - Hung in a loop trace on rhodan /s3 26295 . 1 43 1 4 
icache_perf_5t_l 240 - Hung trace on rhodan /s3 26395 . 1 34 1 4 

doubleextest_0 23 1 - } trace on nosferatu /s2 1 7295.29 146 

doublemctestO 23 1 - } 

hermesjateturnon 23 1 - trace on nosferatu /s2 1 9295 .28510 

cerbstarttest_0 240 - Doesn't seen to have anything in rom? 
Fix check in 


exresedepitestl_0 240 - X 

exreseudepitestl_0 240 - X 

exresemdepitestl_0 240 - X 

exresewthitestl_0 240 - X 

exreseuwthitest 1 _0 240 - X 

exresgdepitestl_0 240 - X 

exresgudepitest 1 _0 240 - X 

exresgmdepitest 1 _0 240 - X 

exresgwth itest 1_0 240 - X 

exresguwthitestl_0 240 - X 


Old Business - Need to reun and if necessary redump these 


xlu_field_4_l 223 - X - Need to re-run 

cerbarbeasyj) Lisa R to run again as verilog run is well behaved 
Performance Failures (Test ran to completion but failed performance measure) 


dcache_perf_ld 1 1_ 1 Expected difference between the cached and non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles 
icache_perf lt l Expected difference between the cached and non-cached access = 46000-50600 cycles 

Actually took 123800 fewer cycles 

Need sync ops: 


nb slow 223 - Running a longgggg time trace on rhodan /s3 7295. 191 05 

nb_combo_l 

dcache_stress_l 

icache_stress_l 

hermes_conflict_l 
dcache_conflict_l 
atomic_conflict_l 

synch_l 

Have not yet been run: 


ruptpintest 0 - Need to build a "custom" simulator 

dcache_except_l 

interrupt_l 

exceptionl 

interleave^ 
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inter Ieave_U 

interrupt_U 

exceptionU 

bgate_U 

mem_U 

tlbU 

synch U 

barrelJJ 

cache_U 

gtlbmissJU 

Cannot yet be run: 


instr_U 
instrl 
tlb_l 
insn_l 
nu litest 

XLU tests 


xlujotate 1 1 
xlu_rotate_2_l 
xlu_expand_l_l 
xlu_compress_ 1 _ 1 
xlu_extract_l_l 
xlu_field 11 
xlu_field_2_l 
xlu_field_3_l 
xlu_copyswap_ 1_ 1 
xlu_copy swap_2_ 1 
xlu_copy swap_3_ 1 
xlu_copy swap_4_ 1 
xlu_shufTlemux_ 1 _1 
xluselectll 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimm longtest_0 

expriotestO 

canceltest_0 

hermtotest 0 

cerbtotest 0 

hermerrtest„0 

eventregtest_0 

exintbashtest_0 

cerb_registers_0 

cerberrorO 

testerinit 0 

memmap_0 

nbbashtest_0 

cerbarbtests 

hcplltests 

Need Special Simulator Support 

hermesloadO 
hermes_load_0 
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From: 
Sent: 
To: 


torn (Tom Laidig (tau)) 

Tuesday, February 28, 1995 9:42 AM 

Tim B. Robinson' 


Cc: 'bill (William Herndon)'; 'lisar (Lisa Robinson)'; 'solo (John Campbell)'; 'Jean-Yves Michel'; 'tau' 
Subject: Re: proteus/ged/BOM 

Tim B. Robinson writes: 

|William Herndon wrote (on Mon Feb 27): 

| I want to make sure that in the euterpe clock tree we are using cged 
j and cgeb not cgdr and cgbfr.. 


jWe are, but there are instances of cgdr in the design somewhere also. 
[I see it get compiled when making an LVS netlist: 

| Compiling CGDR.SPICE.1.1 
j No parameters 

j No errors detected 
j No oversights detected 
| No warnings detected 

| Page compiled (00:00:00.78) 

|But I can't put a finger on where it's being used. 

Well, looking through the layouts, the only things I find that 
instantiate cgdr are rddig and vddig, neither of which is used in 
euterpe. However, I find some uses of sccgdr in pl mnejogic (OK, 
that's used in mnemo, not euterpe) and some uses of scxbcgdrO (how that 
cell got its name remains a mystery to me) in pl_eus_logic and 
pl euh Jogic. Note that both sccgdr and scxbcgdrO have their own 
schematics, so it may be that some schematic is out of date. Do you 
have a .spivs file to grep through? 
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From: solo (John Campbell) 

Sent: Tuesday, February 28, 1995 9:47 AM 

To: Tim B. Robinson' 

Cc: 'bill (William Herndon)'; 'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'Jean-Yves Michel' 
Subject: Re: proteus/ged/BOM 

as Tim B. Robinson was saying 

..We are, but there are instances of cgdr in the design somewhere also. 
..I see it get compiled when making an LVS netlist: 

Compiling CGDR.SPICE.1.1 
No parameters 

.. No errors detected 
.. No oversights detected 
.. No warnings detected 

Page compiled (00:00:00.78) 

..But I can't put a finger on where it's being used. 


.Tim 


in the custom blocks, mnemo and euterpe, the following are the only 
substring cgdr that i could find, must be in the sofa area. 


unless...., the schematic has a reference to cgdr/spice cn.l .1 . i 
will get back to you in a while. 


/u/chip/euterpe/proteus/compass/layouts/scxbcgdrO.ly 
/u/ch ip/euterpe/ proteus/compass/lay outs/sccgdr. ly 


15.4 Oct 14 17:51:56 1994 
13.2 Dec 23 06:40:54 1994 


regards, 

solo a.k.a. John Campbell x5 16 
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From: bill (William Herndon) 

Sent: Tuesday, February 28, 1 995 1 1 :41 AM 

To: 'andrew@charybdis'; 'tbr@microunity.com' 

Cc: 'bi!l@gaea* 

Subject: Re: Calliope cerb only card 

> From tbr@gaea.microunity.com Mon Feb 27 22:38:16 1995 

> Date: Mon, 27 Feb 1995 22:38:13 -0800 

> From: tbr@gaea.microunity.com (Tim B. Robinson) 

> To: "andrew" <andrew@charybdis> 

> Cc: "Bill Herndon" <bill@gaea> 

> Subject: Calliope cerb only card 

> Content-Length: 1341 
> 

> 

> "andrew" wrote (on Feb 27): 

> 

> I'm going to build a probe card to allow us to look at Cerberus only on 

> Calliope 1 . My plan is to power as much Vdd (digital) and Vss as possible, 

> On the analog side, I plan to power each Vpp plane so they are not floating 

> (one probe per plane only). 

> 

> Are there any digital pins that could be a problem if left floating? What 

> are the chances of being able to talk to cerberus with only the 

> peripheral pads powered? 

> 

> Except in so far as they share power, I think Cerberus should be 

> entirely operational independent of anything in the SOFA, so the issue 

> is can we power off all the SOFA knob domains, either my forcing a 

> code 0 from the padring, or by getting emough power in to get Cerberus 

> working well enough to write the knob registers. The problem 1 see 

> there is that the knob registers themselves are physically distributed 

> throught the clock spars. So if a global setting of 0 is not 

> acceptable (as I think bill indicated), and we have to come up at 1, 

> but only have power applied close to Cerberus, we may have too much 

> drop for the CMOS in the spars at the most distant point to operate. 
> 

> Bill, is it really the case that your earlier mail implied that 

> the global setting of 0 cannot be allowed? If so, with the full sofa 

> at knob 1, how much droop will we see? 

> 

>Tim 

> 
> 
> 
> 
> 

First let me say that if we have control of knobs, we can turn all the power off 
by setting 0 voltage swing. When i say knob setting 0 is not allowed it is knob 
resistor value 0 is not allowed, the problem is that that gives us high value 
resistance and we don't know the effect on the bipolar collector base voltage, it 
is a case of infinite resistance and 0 current, leakages will be important. This 
could forward bias a collector base junction sufficiently to setup some sort of 
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latch up condition.. This is possible, not probable. We can probably get by with 
low values of collector base injection.. However if we set the voltage swing 
to 0 and the resistor value to 0, then we guarantee there is no collector base 
forward bias. 
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From: solo (John Campbell) 

Sent: Tuesday, February 28, 1 995 1 1 :49 AM 

To: Tim B. Robinson' 

Cc: 'bill (William Herndon)'; 'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'Jean-Yves Michel' 
Subject: Re: proteus/ged/BOM 

as Tim B. Robinson was saying 

..William Herndon wrote (on Mon Feb 27): 


.We are, but there are instances of cgdr in the design somewhere also. 
.1 see it get compiled when making an LVS netlist: 

. Compiling CGDR. SPICE. 1.1 
No parameters 


. No errors detected 
. No oversights detected 
. No warnings detected 

. Page compiled (00:00:00.78) 

.But I can't put a finger on where it's being used. 

.Tim 


the schematic cgdr is referenced in sccgdr. as follows and is out of 
date. 


Verify/sccgdr/cvscheck.sccgdr:/n/auspex/s 10/chip/euterpe/proteus/ged/cg/cgdr/spice„cn. 1 .1 1 .2 Mar 2 1 6:23 :26 1 994 
Verify/sccgdr/cvscheck.sccgdr:/p/cvsroot/proteus/ged/cg/cgdr/spice_cn.l.l,v Mismatch RCS = 1.3 release = 1.2 


regards, 

solo a.k.a. John Campbell x516 
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From: tbr 

Sent: Tuesday, February 28, 1 995 1 1 :53 AM 

To: 'torn (Tom Laidig (tau)' 

Cc: 'bill (William Herndon)'; 'lisar (Lisa Robinson)'; 'solo (John Campbell)'; 'tau'; 'Jean-Yves 

Michel' 

Subject: Re: proteus/ged/BOM 

Follow Up Flag: Follow up 
Flag Status: Red 


tau wrote (on Tue Feb 28): 
Tim B. Robinson writes: 
jwilliam Herndon wrote (on Mon Feb 27): 

j I want to make sure that in the euterpe clock tree we are using cged 
j and cgeb not cgdr and cgbfr.. 


| We are, but there are instances of cgdr in the design somewhere also. 
|I see it get compiled when making an LVS netlist: 

| Compiling CGDR.SPICE.1.1 
j No parameters 

j No errors detected 
j No oversights detected 
| No warnings detected 

| Page compiled (00:00:00.78) 

[But I can't put a finger on where it's being used. 

Well, looking through the layouts, the only things I find that 
instantiate cgdr are rddig and vddig, neither of which is used in 
euterpe. However, 1 find some uses of sccgdr in pl_mne_logic (OK, 
that's used in mnemo, not euterpe) and some uses of scxbcgdrO (how that 
cell got its name remains a mystery to me) in pl_eus_logic and 
pleuhjogic. Note that both sccgdr and scxbcgdrO have their own 
schematics, so it may be that some schematic is out of date. Do you 
have a .spivs file to grep through? 

Yes, ~tbr/euterpe/verilog/bsrc/euterpe-passl .spivs. It was the log of 
compiling this that I cut the example from, so it must be in there 
somewhere but I could not find it anywhere in the verilog, or in the 
edif file. 

Tim 
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From: torn (Tom Laidig (tau)) 

Sent: Tuesday, February 28, 1995 12:50 PM 

To: Tim B. Robinson' 

Cc: 'bill (William Herndon)'; lisar (Lisa Robinson)'; 'solo (John Campbell)*; 'tau'; 'Jean-Yves Michel' 
Subject: Re: proteus/ged/BOM 

Tim B. Robinson writes: 

[tau wrote (on Tue Feb 28): 

I Tim B. Robinson writes: 
I I 

| [William Hemdon wrote (on Mon Feb 27): 
I I 

| | 1 want to make sure that in the euterpe clock tree we are using cged 
j I and cgeb not cgdr and cgbfr.. 

I I 

| | We are, but there are instances of cgdr in the design somewhere also. 

| |I see it get compiled when making an LVS netlist; 

II 

| |But I can't put a finger on where it's being used, 
j Do you have a .spivs file to grep through? 

j Yes, ~tbr/euterpe/verilog/bsrc/euterpe-passl .spivs. It was the log of 
j compiling this that I cut the example from, so it must be in there 
[somewhere but I could not find it anywhere in the verilog, or in the 
lediffile. 

OK, as solo says, sccgdr instantiates cgdr, and that's the only place 
cgdr is used in euterpe. Sccgdr is used only in the main sofa area. 

By contrast, scxbcgdr contains its own copy of circuitry which I assume 
is similar to that in cgdr. It is used only in pleuslogic and 
pleuh logic. 
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From: vanthof (vant) 

Sent: Tuesday, February 28, 1995 12:55 PM 

To: 'hopper (Mark Hofmann)'; 'torn (Thomas Laidig)'; 'geert (Geert Rosseel)'; 'vo (Tom Vo)'; 'lisar 

(Lisa Robinson)'; 'tbr (Tim B. Robinson)' 
Cc: 'vanthof (Dave Van't Hof)' 

Subject: euterpe drc run started 


I've started another round of euterpe drc checks to make sure no errors have snuck in, 
especially since we are getting close to running an LVS. 
I don't expect any problems. 

Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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From: wayne (Wayne Freitas) 

Sent: Tuesday, February 28, 1995 1:29 PM 

To: 'tbe'; 'jr'; 'pmayer*; 'tbr' 

Cc: 'wayne' 

Subject: PR 1962 

Tom, PR 1962 is for inadequate spacing on the secondare! size under 
Euterpe. You have a solution, if you could take a look and verify this 
we should probable change this to "Analyzed". How do we stand about 
closing this off? 

Thanks, 

Wayne 
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From: tbr 

Sent: Tuesday, February 28, 1995 1:36 PM 

To: 'solo (John Campbell)' 

Cc: 'bill (William Herndon)'; 'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'Jean-Yves Michel' 

Subject: Re: proteus/ged/BOM 
Follow Up Flag: Follow up 

Flag Status: Red 


John Campbell wrote (on Tue Feb 28): 
as Tim B. Robinson was saying 


.William Herndon wrote (on Mon Feb 27): 


We are, but there are instances of cgdr in the design somewhere £ 
I see it get compiled when making an LVS netlist: 


Compiling CGDR. SPICE. 1.1 
No parameters 

No errors detected 
No oversights detected 
No warnings detected 

Page compiled (00:00:00.78) 


.But I can't put a finger on where it's being used. 


.Tim 


the schematic cgdr is referenced in sccgdr. as follows and is out of 
date. 


Verify/sccgdr/cvscheck. sccgdr :/n/auspex/slO/chip/euterpe/proteus/ged/cg/cgdr/spice_cn.l.l 1.2 Mar 2 16:23:26 1994 
Verify/sccgdr/cvscheck.sccgdr:/p/cvsroot/proteus/gedycg/cgdr/spice_cn.l.l,v Mismatch RCS = 1.3 release = 1.2 

regards, 

solo a.k.a. John Campbell x516 

OK, so does this mean we need to change sccgdr, or just release the 
cahnegs in cgdr? 

Tim 
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From: dickson (Richard Dickson) 

Sent: Tuesday, February 28, 1995 2:53 PM 

To: 'jeffm'; 'lisar'; tbr* 

Subject: double machine checks 

tim lisa andjeff 

i just checked in new ce_mchk. V cerberus.V and euterpe. V 
to enable double machine checks, i realized this morning that i 
hadn't done this yet prior to this checkin double machine 
checks had been disabled by a cO 1 (logicO/logicl) at the 
top level. 

dickson 
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From: Hsar (Lisa Robinson) 

Sent: Tuesday, February 28, 1995 2:55 PM 

To: 'dickson (Richard Dickson)' 

Cc: 'jeffm'; 'tbr' 

Subject: double machine checks 

Richard Dickson wrote (on Tue Feb 28): 

tim lisa and jeff 

i just checked in new cemchk. V cerberus.V and euterpe. V 
to enable double machine checks, i realized this morning that i 
hadn't done this yet prior to this checkin double machine 
checks had been disabled by a cOl (logicO/logicl) at the 
top level. 

dickson 

Ah great perhaps that will fix the doulblemctest failure. 
Lisa R. 
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From: solo (John Campbell) 

Sent: Tuesday, February 28, 1 995 3:1 9 PM 

To: Tim B. Robinson' 

Cc: 'bill (William Herndon)'; 'lisar (Lisa Robinson)'; 'torn (Thomas Laidig)'; 'Jean-Yves Michel' 
Subject: Re: proteus/ged/BOM 

as Tim B. Robinson was saying 


.John Campbell wrote (on Tue Feb 28): 


.. the schematic cgdr is referenced in sccgdr. as follows and is out of 
date. 

.. Verify/sccgdr/cvscheck.sccgdr:/ri/auspex/slO/chip/eutenpe/proteus/ged/cg/cga>/sp]ce_cn.l.l 1,2 Mar 2 16:23:26 
1994 

.. Verify/sccgdr/cvscheck.sccgdr:/p/cvsroot/proteus/ged/cg/cgdr/spice_cn. 1 . 1 ,v Mismatch RCS - 1 .3 release = 1 .2 


.. regards, 

.. solo a.k.a. John Campbell x516 

..OK, so does this mean we need to change sccgdr, or just release the 
..cahnegs in cgdr? 

..Tim 

i think i would vote for release the cahnegs in cgdr. 
regards, 

solo a.k.a. John Campbell x5 1 6 
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From: bill (William Herndon) 

Sent: Tuesday, February 28, 1 995 3:44 PM 

To: 'tbr@mjcrounity.com'; 'solo' 

Cc: 'lisar'; 'torn'; 'yves' 

Subject: Re: proteus/ged/BOM 

> From solo Tue Feb 28 13:18:56 1995 

> From: solo (John Campbell) 

> Subject: Re: proteus/ged/BOM 

> To: tbr@echidna.microunity.com (Tim B. Robinson) 

> Date: Tue, 28 Feb 95 13:18:50 PST 

> Cc: bill (William Herndon), lisar (Lisa Robinson), torn (Thomas Laidig), 

> yves (Jean- Yves Michel) 

> X-Mailer: ELM [version 2.3 PL1I] 

> Content-Length: 722 

> 

> as Tim B. Robinson was saying 

> ..John Campbell wrote (on Tue Feb 28): 
> .. 

> .. 

> .. the schematic cgdr is referenced in sccgdr. as follows and is out of 
>.. date. 

> .. 

> . . Verify /sccgdr/cvscheck. sccgdr :/n/auspex/s 1 0/chip/euterpe/proteus/ged/cg/cgdr/spice_cn. 1.1 1 .2 Mar 2 1 6:23 :26 
1994 

> .. Verity/sccgdr/cvscheck. sccgdr :/p/cvsroot/proteus/ged/cg/cgdr/spice_cn. 1 . 1 ,v Mismatch RCS = 1 .3 release = 1 .2 

> ,, 

> 

> .. regards, 

in my proteus/ged/cg there is a cgdr with eout on the output switch emitter node i can release this at 5:00 
if that is what is desired., i guess i go to eg (one level up from the cgdr directory) and releasebom cgdr 
before i do so, i want confirmation from tbr, solo, lisar, torn that that is what is desired. 

> .. solo a.k.a. John Campbell x516 

> .. 

> ..OK, so does this mean we need to change sccgdr, or just release the 

> ..cahnegs in cgdr? 

> ,. 

> ..Tim 
> .. 

> i think i would vote for release the cahnegs in cgdr. 

> 

> .... 

> regards, 

> solo a.k.a. John Campbell x5 1 6 

> 
> 
> 
> 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, February 28, 1 995 5:30 PM 

To: Vo'; 'geert' 

Subject: forwarded message from "andrew" 


Start of forwarded message 

Status: RO 

X-VM-v5-Data: ( [nil nil nil nil nil nil nil nil nil] 

["838" "" "2B tt "February" "1995" "14:32:33" "-0800" "\"andrew\"" 
"andrew@charybdis" nil "16" "Cerberus Stuff" " A From:» nil nil "2"]) 
Re turn- Pa th: < andrew® c ha ry bd i s > 

Received: from charybdis (charybdis.microunity.com) by gaea.microunity.com 
(4 . 1/musel . 3 ) 

id AA2 914 0; Tue, 28 Feb 95 14:31:07 PST 
Message-Id: <9502282231 . AA29140@gaea .microunity . com> 
From: "andrew" <andrew@charybdis> 
To: "Lisa Robinson" <lisar@gaea> 
Subject: Cerberus Stuff 
Date: 28 Feb 1995 14:32:33 -0800 

Lisa 

Do you know what controls the following calliope pads. I've gone through the Terp doc but 
could find no mention of them. Also, I think the last one, au_loop is in fact a Hermes 
control and not cerb as the name implies. 

Andrew 


t2cfg0_abm padttl # Spare 

applications 

t2cfgl_abm padttl # Spare 

applications 

t2cfg2_abm padttl # Spare 

applications 

t2cfg3_abm padttl # Spare 

applications 

t2cfg4_abm padttl # Spare 

applications 

t2cfg5_abm padttl # Spare 

applications 

t2cfg6_abm padttl # Spare 

applications 

auloop_abm padttl # Spare 

applications 

End 0 f forwarded message 


cerberus 
cerberus 
cerberus 
cerberus 
cerberus 
cerberus 
cerberus 
cerberus 


controlled pads 
controlled pads 
controlled pads 
controlled pads 
controlled pads 
controlled pads 
controlled pads 
controlled pads 


for future 
for future 
for future 
for future 
for future 
for future 
for future 
for future 
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From: tbr 

Sent: Tuesday, February 28, 1995 8:48 PM 

To: 'bill (William Herndon)' 

Cc: 'lisar"; 'solo'; 'torn'; 'yves' 

Subject: Re: proteus/ged/BOM 
Follow Up Flag: Follow up 

Flag Status: Red 


William Herndon wrote (on Tue Feb 28): 


> From solo Tue Feb 28 13:18:56 1995 

> From: solo (John Campbell) 

> Subject: Re: proteus/ged/BOM 

> To: tbr@echidna.microunity.com (Tim B. Robinson) 

> Date: Tue, 28 Feb 95 13:18:50 PST 

> Cc: bill (William Herndon), lisar (Lisa Robinson), torn (Thomas Laidig), 

> yves (Jean- Yves Michel) 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content-Length: 722 

> 

> as Tim B. Robinson was saying 

> .. 

> .. 

> .John Campbell wrote (on Tue Feb 28): 

> .. 

> .. .. 

> .. the schematic cgdr is referenced in sccgdr. as follows and is out of 
>.. date. 

> .. 

> . . Verify/sccgdr/cvscheck.sccgdr:/n/auspex/s 1 0/chip/euterpe/proteus/ged/cg/cgdr/spice_cn. 1.1 1 .2 Mar 2 16:23:26 
1994 

> .. Veriry/sccgdr/cvscheck.sccgdr:/p/cvsroot/proteus/ged/cg/cgdr/spice_cn. 1 . 1 ,v Mismatch RCS = 1 .3 release = 1 .2 

> .. 

> 

> .. regards, 

in my proteus/ged/cg there is a cgdr with eout on the output switch emitter node i can release this at 5:00 
if that is what is desired., i guess i go to eg (one level up from the cgdr directory) and releasebom cgdr 
before i do so, i want confirmation from tbr, solo, lisar, torn that that is what is desired. 

I released at the eg level, what I actually want is a release at the 
ged level to pick up the Makefiles there. Asside from a layout_equiv 
property change in the ra section, everything else is already 
released, but there is a technical problem with some stuff being 
locked, for which I still need assistance from torn! 

Tim 
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From: dickson (Richard Dickson) 

Sent: Tuesday, February 28, 1995 9:21 PM 

To: 'euterpe' 

Subject: at.V 


you' all 

beware of at.V -rl. 3 9 i broke it !!! 
-rl.4 0 has a fixup in it . i 

! 

dickson 


Exhibit Cll 


Page 557 of 559 


Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, February 28, 1995 11:20 PM 

'mws (Mark Semmelmeyer)' 

'billz'; 'dickson'; 'geert'; 'mws'; 'woody' 

Re: uu in bad shape again ... 


Mark Semmelmeyer wrote (on Tue Feb 28) : 

I am trying to release a BOM with a new uu with bug fixes 
but no placement, so it would be better to start with that. 

Mark, can you be sure to get rich's fixes in this BOM, lisar needs them urgently. This 
includes the euterpe.V change and the stuff in ce. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Tuesday, February 28, 1 995 1 1 :55 PM 

To: 'fwo' 

Cc: 'geert'; 'torn' 

Subject: csyn problem 


My latest run is reporting things like: 


error ( Exclusive Inputs wingCheck . 109) in file "euterpe-passl . spivs" 
drivers fail exclusive input swing requirement 


Reason: Two e inputs. 

exclusive inputs 
instance path: 
cellname path: 
instance path: 
cellname path: 

drivers 

instance path 
cellname path 
instance path 
cellname path 


exclusive topmost nets 


Use diff. instead 

top . xdrdroutmuxf f 2_16samplehiu3 . 
t op . xbmuxf f 2 dh2 s 

top .xdrdroutmuxf f 2_16samplehiu3 , 
t op . xbmux f f 2 dh2 s 

top . xdrdrsamplephaseusamplehiuO , 
top. xborf f2dh6s 

top . xdrdrsamplephaseusamplehiuO , 
top. xborf f 2dh6s 


. dr_samplehi 
, sel_aOpeh_l 
. dr_samplehi_n 
, sel_a0peh_0 

. dr_samplehi 
. q_ad0ph 
. dr_samplehi_n 
, q_and0ph 


instance path 
cellname path 
instance path 
cellname path 


top . dr_samplehi 
top . dr_samplehi 
top . dr_samplehi_n 
top . dr_samplehi_n 


Is this trying to tell me that we need to change the pin names on the 

2 input mux selects? As far as I can see the driver is a single differential output, 
have about 7MB of errors, and its almost all this case. 


Tim 


Exhibit Cll 


Page 559 of 559 


